[Discuss-gnuradio] A question about the 'next' branch

[Carles Fernandez]

Hi there,

I've seen that recently there are merges to the 'master' branch which also
apply to the 'next' branch, but the last commit there is from more than one
month ago. I was using the 'next' branch to make sure that our blocks will
be ready for GNU Radio 3.8 whenever it is released. Should I now switch to
'master' for that purpose?

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

Re: [Discuss-gnuradio] samp_rate in GNU Radio

[Carles Fernandez]

Hi,

as far as I know, RTL-based dongles cannot deliver samples at 38.192 MS/s,
they are limited to 2.4 MS/s.

Best regards,
Carles








On Mon, Apr 9, 2018 at 3:14 PM, PRIYANKA PRIYADARSHINI <
priyankapriyadarshini...@gmail.com> wrote:

> Hi,
>
> Thank you for your response, I got your point. But I need to know this:
>
> I want to receive a GPS L1 signal (1575.42MHz) and I studied that the
> local oscillator of RTL-SDR has the intermediate frequency of
> 3.57MHz-4.57MHz. So when the signal with this IF goes to ADC of SDR, I want
> my ADC to sample this incoming signal at a sampling rate of 38.192MHz (as
> per the requirement). But when I try to put this sample rate in RTL-SDR, it
> starts dropping samples. I want to know that is there anything am I doing
> wrong OR it is the limitation of my RTL-SDR.
>
> Thank you.
>
> On Mon, Apr 9, 2018 at 11:57 AM, Carles Fernandez <
> carles.fernan...@gmail.com> wrote:
>
>> Dear Priyanka,
>>
>> According to https://www.rtl-sdr.com/about-rtl-sdr/ :
>>
>> The maximum sample rate is 3.2 MS/s (mega samples per second). However,
>> the RTL-SDR is unstable at this rate and may drop samples. The maximum
>> sample rate that does not drop samples is 2.4 MS/s, however some people
>> have had luck with 2.8MS/s and 3.2 MS/s working well on some USB 3.0 ports.
>>
>> Thus, something between 2.0 and 2.4 MS/s would work for you.
>>
>> Maybe this paper could be of your interest, although it is a little bit
>> outdated:
>> http://www.cttc.es/wp-content/uploads/2013/09/Turning_TV_int
>> o_GNSS_Rx1.pdf
>>
>>
>> Hope this helps,
>> Carles
>>
>>
>>
>>
>> On Mon, Apr 9, 2018 at 11:38 AM, PRIYANKA PRIYADARSHINI <
>> priyankapriyadarshini...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am trying to receive GPS signal using RTL-SDR with GNU Radio. I am
>>> interested in L1 band of GPS signal (1575.42MHz). But I am confused about
>>> my sampling frequency. What value should I choose as samp_rate in RTL-SDR
>>> block of gnuradio?
>>>
>>> Thank you
>>> Priyanka
>>>
>>> ___
>>> 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] samp_rate in GNU Radio

[Carles Fernandez]

Dear Priyanka,

According to https://www.rtl-sdr.com/about-rtl-sdr/ :

The maximum sample rate is 3.2 MS/s (mega samples per second). However, the
RTL-SDR is unstable at this rate and may drop samples. The maximum sample
rate that does not drop samples is 2.4 MS/s, however some people have had
luck with 2.8MS/s and 3.2 MS/s working well on some USB 3.0 ports.

Thus, something between 2.0 and 2.4 MS/s would work for you.

Maybe this paper could be of your interest, although it is a little bit
outdated:
http://www.cttc.es/wp-content/uploads/2013/09/Turning_TV_into_GNSS_Rx1.pdf


Hope this helps,
Carles




On Mon, Apr 9, 2018 at 11:38 AM, PRIYANKA PRIYADARSHINI <
priyankapriyadarshini...@gmail.com> wrote:

> Hi,
>
> I am trying to receive GPS signal using RTL-SDR with GNU Radio. I am
> interested in L1 band of GPS signal (1575.42MHz). But I am confused about
> my sampling frequency. What value should I choose as samp_rate in RTL-SDR
> block of gnuradio?
>
> Thank you
> Priyanka
>
> ___
> 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] GNU Radio - GNSS SDR Installation

[Carles Fernandez]

You can also do that:

$ sudo apt-get install libgoogle-glog-dev

On Fri, Jun 17, 2016 at 2:18 PM, Berat Atmaca  wrote:

> Ohh sorry. I forgot to attach it. Now it is attached.
>
> -- Berat
>
> --
> From: carles.fernan...@gmail.com
> Date: Fri, 17 Jun 2016 10:00:40 +0200
> Subject: Re: [Discuss-gnuradio] GNU Radio - GNSS SDR Installation
> To: beratatm...@live.com
> CC: cuervonico...@gmail.com; gnss-sdr-develop...@lists.sourceforge.net;
> discuss-gnuradio@gnu.org
>
>
> Dear Berat,
>
> looks like you have forgot the attachment... could we see the errors you
> get when building gnss-sdr?
>
> Best regards,
> Carles
>
>
>
>
> On Fri, Jun 17, 2016 at 9:00 AM, Berat Atmaca 
> wrote:
>
> Hi Nicolas,
>
> After typing "$ gnuradio-companion" on Terminal, I could start using gnu
> radio. Thank you. The only problem is that I dont have any shortcut on
> desktop and still there is no icon on "search your computer"  but it is
> okay.
>
> Also, to install gnss-sdr I typed " pybombs install gnss-sdr"
> but I got an error shown on the file attached to the mail. Do you know
> what is missing for that?
>
> Regards,
>
> --Berat
> --
> From: cuervonico...@gmail.com
> Date: Thu, 16 Jun 2016 14:47:01 -0700
> Subject: Re: [Discuss-gnuradio] GNU Radio - GNSS SDR Installation
> To: beratatm...@live.com
> CC: discuss-gnuradio@gnu.org
>
>
> Hi Berat,
>
> Could you tell us what type of failure are you getting? You could copy and
> paste the error here to the mailing list.
>
> Also, after sourcing the setup_env.sh you should be able to run the in the
> same shell the following command:
>
>$  gnuradio-companion
>
> to open the grc. Are you able to?
>
> Best regards,
>
> Nicolas
>
> On Thu, Jun 16, 2016 at 2:11 PM, Berat Atmaca 
> wrote:
>
> Hi all,
>
> I am a beginner user of USRP N210 for GNSS SDR applications. Yesterday, I
> tried to install GNU Radio on ubuntu via PyBombs. The instructions I have
> typed on Terminal are below:
>
> $ sudo apt-get install git python-pip
>
> $ sudo pip install git+https://github.com/gnuradio/pybombs.git
>
> $ pybombs recipes add gr-recipes 
> git+https://github.com/gnuradio/gr-recipes.git
> $ pybombs recipes add gr-etcetera 
> git+https://github.com/gnuradio/gr-etcetera.git
>
> $ pybombs prefix init /home/computer/sdr -a myprefix -R gnuradio-default
>
> As far as I tracked on Terminal all dependiances were installed
> succesfully.  Then I typed the code below to setup everything for GNU Radio
> Companion.
>
> $ cd /home/computer/sdr
> $ . ./setup_env.sh
>
> The README file of the gnss-sdr says after that code I would be able to
> use GRC. However, I couldn't find any desktop icon or gnu radio related
> executable program on computer.
>
> Still, I tried to continue installation and typed gnss-sdr install code:
>
> $ pybombs install gnss-sdr
>
> It downloaded a few packages and then tried to build them. However, it
> ended up with a failure.
>
> As far as I understood I did a mistake for set up of the downloaded files.
> So, what do you think I should do?
>
> Thank you very much in advance,
>
> Best regards,
>
> -- Berat Atmaca
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
> Nicolás Cuervo Benavides
> Handy: +49 157 70476855
> Electric and Electronic Engineering department.
> Electronic Engineering
> Universidad Nacional de Colombia
> --
> Student M.Sc. Information and Communication Technology
> Karlsruher Institut für Technologie
> Karlsruhe, Baden Württemberg, Germany
>
> ___
> 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] GNU Radio - GNSS SDR Installation

[Carles Fernandez]

Dear Berat,

looks like you have forgot the attachment... could we see the errors you
get when building gnss-sdr?

Best regards,
Carles




On Fri, Jun 17, 2016 at 9:00 AM, Berat Atmaca  wrote:

> Hi Nicolas,
>
> After typing "$ gnuradio-companion" on Terminal, I could start using gnu
> radio. Thank you. The only problem is that I dont have any shortcut on
> desktop and still there is no icon on "search your computer"  but it is
> okay.
>
> Also, to install gnss-sdr I typed " pybombs install gnss-sdr"
> but I got an error shown on the file attached to the mail. Do you know
> what is missing for that?
>
> Regards,
>
> --Berat
> --
> From: cuervonico...@gmail.com
> Date: Thu, 16 Jun 2016 14:47:01 -0700
> Subject: Re: [Discuss-gnuradio] GNU Radio - GNSS SDR Installation
> To: beratatm...@live.com
> CC: discuss-gnuradio@gnu.org
>
>
> Hi Berat,
>
> Could you tell us what type of failure are you getting? You could copy and
> paste the error here to the mailing list.
>
> Also, after sourcing the setup_env.sh you should be able to run the in the
> same shell the following command:
>
>$  gnuradio-companion
>
> to open the grc. Are you able to?
>
> Best regards,
>
> Nicolas
>
> On Thu, Jun 16, 2016 at 2:11 PM, Berat Atmaca 
> wrote:
>
> Hi all,
>
> I am a beginner user of USRP N210 for GNSS SDR applications. Yesterday, I
> tried to install GNU Radio on ubuntu via PyBombs. The instructions I have
> typed on Terminal are below:
>
> $ sudo apt-get install git python-pip
>
> $ sudo pip install git+https://github.com/gnuradio/pybombs.git
>
> $ pybombs recipes add gr-recipes 
> git+https://github.com/gnuradio/gr-recipes.git
> $ pybombs recipes add gr-etcetera 
> git+https://github.com/gnuradio/gr-etcetera.git
>
> $ pybombs prefix init /home/computer/sdr -a myprefix -R gnuradio-default
>
> As far as I tracked on Terminal all dependiances were installed
> succesfully.  Then I typed the code below to setup everything for GNU Radio
> Companion.
>
> $ cd /home/computer/sdr
> $ . ./setup_env.sh
>
> The README file of the gnss-sdr says after that code I would be able to
> use GRC. However, I couldn't find any desktop icon or gnu radio related
> executable program on computer.
>
> Still, I tried to continue installation and typed gnss-sdr install code:
>
> $ pybombs install gnss-sdr
>
> It downloaded a few packages and then tried to build them. However, it
> ended up with a failure.
>
> As far as I understood I did a mistake for set up of the downloaded files.
> So, what do you think I should do?
>
> Thank you very much in advance,
>
> Best regards,
>
> -- Berat Atmaca
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
> Nicolás Cuervo Benavides
> Handy: +49 157 70476855
> Electric and Electronic Engineering department.
> Electronic Engineering
> Universidad Nacional de Colombia
> --
> Student M.Sc. Information and Communication Technology
> Karlsruher Institut für Technologie
> Karlsruhe, Baden Württemberg, Germany
>
> ___
> 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] Adding project info to CGRAN

[Carles Fernandez]

Hi,

any news on this? We included the MANIFEST.md file in our repo some days
ago, but the information is still not reflected at CGRAN. Any help would be
appreciated.

Best regards,
Carles



On Tue, Oct 27, 2015 at 3:15 PM, Carles Fernandez <
carles.fernan...@gmail.com> wrote:

> Dear all,
>
> a few days ago we uploaded the MANIFEST.md file to gnss-sdr at
> https://github.com/gnss-sdr/gnss-sdr
>
> The project already appears at CGRAN, but the associated information does
> not.
>
> Is there any other required step in order to upload the project info to
> CGRAN?
>
> Thanks in advance,
> Carles
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Adding project info to CGRAN

[Carles Fernandez]

Dear all,

a few days ago we uploaded the MANIFEST.md file to gnss-sdr at
https://github.com/gnss-sdr/gnss-sdr

The project already appears at CGRAN, but the associated information does
not.

Is there any other required step in order to upload the project info to
CGRAN?

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

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Carles Fernandez]

Hi Michael,

Issues with boost disappeared with your last push. However, it seems that
all the code you link to boost/gnuradio libraries needs "-stdlib=libc++
-std=c++11" to work properly.

This is an example of a C++ out-of-tree project linked to GNU Radio
installed via macports in Mavericks:

http://gnss-sdr.org/documentation/building-guide#MacOSX

Best regards,
Carles






On Sat, Nov 9, 2013 at 9:21 PM, Michael Dickens
wrote:

> That's great, Carles!  Did you have issues with Boost, as per some reports
> in MacPorts ticket < https://trac.macports.org/ticket/41162 >?  If so, do
> you remember what you did to work around them?  Thanks for the feedback. -
> MLD
>
> On Nov 9, 2013, at 5:00 AM, Carles Fernandez 
> wrote:
> > I've tried 'sudo port install gnuradio-devel' on OSX 10.9 and it works
> fine. The C++ API and runtime are completely usable; when linked from an
> out-of-tree project, everything runs smoothly.
> --
> Michael Dickens, Mac OS X Programmer
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: http://www.ettus.com
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Carles Fernandez]

Hi Michael,

I've tried 'sudo port install gnuradio-devel' on OSX 10.9 and it works
fine. The C++ API and runtime are completely usable; when linked from an
out-of-tree project, everything runs smoothly.

Best regards,
Carles





On Sat, Nov 9, 2013 at 3:15 AM, Michael Dickens
wrote:

> One further update: I played around with the SWIG provided includes for
> std, and it seems possible to tweak them to allow GNU Radio to be fully
> usable on 10.9.  It's something that needs to come from upstream (the SWIG
> folks), since they need to "#ifdef CXX11" or something around the code.
>  But, it works with only a minor change to gnuradio.i which is fully
> backwards compatible.  I probably won't get back to this before Monday
> (busy weekend), but I wanted to extend the hope to others of using GRC with
> OSX 10.9. - MLD
>
> On Nov 8, 2013, at 1:02 PM, Michael Dickens 
> wrote:
> > I just pushed < https://trac.macports.org/changeset/113092 >, which
> allows exactly what you wrote there Carles: just the C++ API and runtime.
>  No SWIG Python or GRC.  Python is used during the build, but not used for
> runtime.  It should be live by ~1:30 PM/US/ET.  I'm love to hear feedback
> from anyone trying to use GNU Radio on 10.9 via MacPorts.
> --
>
> Michael Dickens, Mac OS X Programmer
>
> Ettus Research Technical Support
>
> Email: supp...@ettus.com
>
> Web: http://www.ettus.com
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Carles Fernandez]

Hi Michael,

thanks so much for your efforts and for keeping us updated on your
progress. I'm some steps behind of you but reproducing the path the best I
can. I successfully built GNU Radio runtime, pmt, blocks, fft, filter, uhd,
fec, trellis, analog, and volk libraries with 10.9's clang and libc++,
which is enough for my C++ application. Any one else would be interested in
a 'gnuradio-devel-mavericks' port with the libraries that compile well by
now?




On Thu, Nov 7, 2013 at 6:58 PM, Michael Dickens
wrote:

> On Nov 6, 2013, at 8:25 AM, Michael Dickens 
> wrote:
> > Today I will see if the C++ parts of GNU Radio work on 10.9, without the
> SWIG Python interface.
>
> I finally got all of the dependencies installed, and have verified that
> the GNU Radio codebase does indeed work with 10.9's clang and libc++.  So,
> the issue is purely that SWIG is not generating C++11 compliant code.  I
> will next look into whether SWIG can even do that (at all; some special
> flag) or whether OSX 10.9 users are "out on a limb" for using the GRC and
> Python interfaces to GNU Radio. - MLD
> --
>
> Michael Dickens, Mac OS X Programmer
>
> Ettus Research Technical Support
>
> Email: supp...@ettus.com
>
> Web: http://www.ettus.com
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Use of RTL-based dongles as GNSS receivers

[Carles Fernandez]

Dear all,

it is our pleasure to share a preprint of the paper we presented last week
at the ION GNSS+ 2013 conference (http://www.ion.org/gnss/index.cfm) about
the use of RTL-based dongles as RF front-ends for software-defined GPS
receivers. You can download it by accepting the copyright disclaimer at
http://www.cttc.es/publication/turning-a-television-into-a-gnss-receiver/

The link has been also included here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/AcademicPapers

Any feedback would be more than welcome, either here, or at the
gnss-sdr-developers mailing list (
http://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers), or by
direct email.

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

Re: [Discuss-gnuradio] How to use USRP to detect and collect weak satellite signals

[Carles Fernandez]

Hi there,

for those folks interested in GPS (and Galileo) signal processing with
USRP+DBSRX and GNU Radio related stuff, please take a look at the
publications available at http://gnss-sdr.org/documentation/publications

We use three VOLK-based correlators for GPS L1 and five for Galileo. An
active antenna is also desirable, but any cheap ($20) commercial part
should work well.

Best regards,
Carles




On Fri, Sep 6, 2013 at 9:38 PM, Marcus D. Leech  wrote:

>  On 09/06/2013 03:33 PM, Ian Buckley wrote:
>
>
>  Filters will all to some degree attenuate your signal of interest, but
> by how much varies dramatically depending on the type and design of the
> filter, it could be 0.5dB or 20dB, but the point is that it attenuates
> potential interferers and noise by a great amount. An LNA cascaded into a
> bandpass filter as close as possible to the antenna is generally an ideal
> setup for this type of weak signal work.
>
>  LNA into filter is the line-up we use in radio astronomy, which might be
> described as the "limiting case" of weak-signal work.
>
> A circular-waveguide feedhorn designed for the band of interest will act
> as a high-pass filter with a "knee" at the design frequency of the
> feedhorn.  This,
>   combined with directionality of a dish is often enough to eliminate the
> worst of the interferers *before* the LNA, and then apply a filter after
> the LNA.
>
> ___
> 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] Compiling error from a commit from yesterday

[Carles Fernandez]

Now it works :-)

Thanks Johnathan!


On Sun, May 26, 2013 at 3:00 PM, Johnathan Corgan
wrote:

> On Sun, May 26, 2013 at 5:30 AM, Johnathan Corgan <
> johnat...@corganlabs.com> wrote:
>
>> On Sun, May 26, 2013 at 3:43 AM, Carles Fernandez <
>> carles.fernan...@gmail.com> wrote:
>>
>>
>>> This error was introduced by revision beb44631, since it was not present
>>> before. It seems that in standard C++ the length of the array needs to be a
>>> compile time constant, maybe a vector could be used there.
>>>
>>
>> Good catch, will fix shortly.
>>
>
> This has been fixed, please test.
>
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Compiling error from a commit from yesterday

[Carles Fernandez]

Hi there,

I pulled the next branch and tried to compile it on Mac OS X 10.8.3 with
clang++. I've found this error:

...
[ 62%] Building CXX object
gr-analog/lib/CMakeFiles/gnuradio-analog.dir/quadrature_demod_cf_impl.cc.o
/Users/carlesfernandez/gnuradio/gr-analog/lib/quadrature_demod_cf_impl.cc:67:21:
error: variable length array of non-POD element type
  'gr_complex' (aka 'complex')
  gr_complex tmp[noutput_items];
^
1 error generated.
make[2]: ***
[gr-analog/lib/CMakeFiles/gnuradio-analog.dir/quadrature_demod_cf_impl.cc.o]
Error 1
make[1]: *** [gr-analog/lib/CMakeFiles/gnuradio-analog.dir/all] Error 2
make: *** [all] Error 2


This error was introduced by revision beb44631, since it was not present
before. It seems that in standard C++ the length of the array needs to be a
compile time constant, maybe a vector could be used there.

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

Re: [Discuss-gnuradio] Budget Radio Telescope: DRAFT document

[Carles Fernandez]

Dear Marcus,

thanks for sharing this document. It happens that I'm writing a paper about
the use of RTL2832U-based dongles applied to software radio (well,
specifically about their use as GNSS receivers), and I would like to
reference your work on radioastronomy as a example of other possible uses
of those dongles. ¿What would be the correct way to reference it? Do you
have any paper already published, or do you plan to publish something in
the following months? I can refer this document you sent as "Unpublised
work", but maybe you prefer that I cite another reference. Please let me
know. I have to deliver my paper next September, so there is still time in
case you are planning to submit your work somewhere.

For the curious minds, those dongles have been already used for building
software-defined oscilloscopes and spectrum analyzers, to the
identification of interference sources, FM and AM demodulation, Automatic
Dependent Surveillance-Broadcast (ADS-B) decoding, LTE cell scanning, an
Automatic Identification System (AIS) receiver for electronic tracking, and
even downloading NOAA satellite pictures. It seems that I should add
radioastronomy to that list!

Best regards,
Carles





On Tue, May 21, 2013 at 2:52 AM, Marcus D. Leech  wrote:

> Some, very small, fraction of the assemblage here might find this relevant
> and/or interesting:
>
> http://www.sbrac.org/files/**budget_radio_telescope.doc
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Announcing new scheduler for GNU Radio

[Carles Fernandez]

Hi,

thanks Josh for this email, it's a great source of information! Let me ask
a couple of questions: Will GRAS be included in the GNU Radio 3.7 release?
Will users be able to select what scheduler they want to use (the current
one or GRAS), or is GRAS going to replace the current scheduler?

Best regards,
Carles




On Wed, Apr 17, 2013 at 10:26 AM, Josh Blum  wrote:

> Hey folks,
>
> I have been working on a new scheduler for GNU Radio, called the GNU
> Radio Advanced Scheduler (GRAS). GRAS is a complete re-write and
> overhaul of the stock GNU Radio scheduler to implement new features,
> performance enhancements, and a simplified user API. A new buffer and
> threading model gives GRAS zero copy features, allowing integration of
> DMA devices and seamless transition between stream and packet domains.
> Here is the main project wiki page:
>
> https://github.com/guruofquality/gras/wiki
>
> Each feature has a mini-description on the Summary wiki with a link to
> greater detail and code examples. I think there is something in this
> project for everyone; whether you are into API design, models of
> computation, concurrency mechanisms, zero-copy, data flow topology...
>
> https://github.com/guruofquality/gras/wiki/Summary
>
> Nobody gives a lick about features without the horsepower! I have
> benchmarks on two PC variants: operton and i7. I am happy to report that
> the features do indeed offer performance benefits, and that GRAS is up
> to the challenge. The operton benchmarks look great, however I would
> like to see better results on the i7.
>
> https://github.com/guruofquality/gras/wiki/Benchmarks
>
> Behind all of the GRAS fluff, the Theron C++ concurrency library is the
> real scheduler; driving all of the work dispatching, threading, and
> synchronization. I have to give a special thanks to Ashton Mason for
> creating the Theron library. Both Theron and Ashton were a pleasure to
> work with.
>
> http://www.theron-library.com/
>
> Whats next/whats in the queue for GRAS?
>
> Characterization. I need to run the benchmark suite on more platforms to
> get a better idea about how design decisions and trade-offs affect the
> performance. And I will try to optimize some of the more troubled
> benchmarks.
>
> GR Wrapper. The current wrapper that makes the GNU Radio blocks work on
> top of GRAS has seen a lot of development history. I plan to rewrite
> this wrapper to be slimmer and to reuse as much code as possible; much
> like the style of the new gnuradio-runtime component.
>
> Theron. A new version of Theron (v6) is in the works, with runtime
> selectable schedulers for different synchronization schemes, backoff
> mechanisms, and work dispatching optimizations. My hope is that this
> capability will allow users to easily optimize their applications for a
> particular architecture.
>
> Phew, that was a wordy email! Thoughts, feedback?
>
> -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] Google Summer of Code: We're in!

[Carles Fernandez]

Thanks Martin, those were my guesses as well. I just wanted to make sure
that I didn't miss something. I don't understand, either, the reason why
there is not a MASSIVE number of applications. Could it be lack of
advertisement? Fear of not being "good enough"? Students having a life?

Lets try to improve the figures this year!

Best regards,
Carles






On Tue, Apr 9, 2013 at 5:30 PM, Martin Braun (CEL) wrote:

> On Tue, Apr 09, 2013 at 04:44:50PM +0200, Carles Fernandez wrote:
> > do you know how the slot allocation works? Is there a fixed number of
> slots per
> > organization or it depends on the number of received proposals? Any clue
> would
> > be welcome.
>
> Different orgs did get different # of slots in the past. However,
> there's no official description re. the slot allocation; I assume Google
> takes all the available info (# of mentors, # of ideas, amount of $$$,
> random other facts) and then decides somehow.
>
> It's not that easy to fill lots of slots, though, despite GSoC probably
> being the best thing a student can do over summer. Orgs will probably
> have to earn the right to get lots of slots, having to prove they can
> handle it.
>
> All of this is guesswork, though!
>
> 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
>
> ___
> 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] Google Summer of Code: We're in!

[Carles Fernandez]

Hi guys,

do you know how the slot allocation works? Is there a fixed number of slots
per organization or it depends on the number of received proposals? Any
clue would be welcome.

Best regards,
Carles






On Tue, Apr 9, 2013 at 4:30 PM, Sreeraj Rajendran
wrote:

> Kudos Martin...:). That too as a stand-alone project...cool(expecting more
> project slots this time).
>
> P.S. For those who are applying: Don't allow Martin to escape from
> mentoring. He is a cool guy to work with :).
>
> ---
> Regards
> Sreeraj Rajendran
> http://home.iitb.ac.in/~rsreeraj
>
>   --
> *From:* Martin Braun (CEL) 
> *To:* discuss-gnuradio@gnu.org
> *Sent:* Tuesday, 9 April 2013 3:06 AM
> *Subject:* [Discuss-gnuradio] Google Summer of Code: We're in!
>
> Hi everyone!
>
> I'm happy to say we've been accepted for GSoC 2013!
>
> Our GSoC page is up and running at
> http://www.google-melange.com/gsoc/org/google/gsoc2013/gnuradio.
>
> We'll be adding details soon. Students, how about making some $$$
> writing code for the community? Check out our ideas page.
>
> Cheerio,
> 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
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Google Summer of Code: We're in!

[Carles Fernandez]

Hi JM,

could you post what did you do and what was the error? Maybe we can move
this discussion to the GNSS-SDR developers mailing list
http://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers

Best regards,
Carles




On Tue, Apr 9, 2013 at 2:10 PM, jmfriedt  wrote:

> most enthusiastic about this development: I was disappointed not to get
> the current
>
> http://www.gnss-sdr.org/documentation/gnss-sdr-operation-realtek-rtl2832u-usb-dongle-dvb-t-receiver
> running on my dongle and am really looking forward to some demo on this
> topic.
>
> JM
>
>
> > Congratulations for the acceptance in GSoC! I'm happy to announce that
> > GNSS-SDR (an open source GNSS receiver based on GNU Radio) has been also
> > accepted as well as a mentoring organization this year:
> > http://www.google-melange.com/gsoc/org/google/gsoc2013/gnss_sdr
> >
> > Students: get ready to have fun this summer! :-)
> >
> > Best regards,
> > Carles
> >
> >
> >
> >
> > On Tue, Apr 9, 2013 at 2:15 AM, Tom Rondeau  wrote:
> >
> > > Nice work, Martin.
> > >
> > > Tom
> > >
> > >
> > >
> > > On Mon, Apr 8, 2013 at 5:36 PM, Martin Braun (CEL) <
> martin.br...@kit.edu>
> > > wrote:
> > > > Hi everyone!
> > > >
> > > > I'm happy to say we've been accepted for GSoC 2013!
> > > >
> > > > Our GSoC page is up and running at
> > > > http://www.google-melange.com/gsoc/org/google/gsoc2013/gnuradio.
> > > >
> > > > We'll be adding details soon. Students, how about making some $$$
> > > > writing code for the community? Check out our ideas page.
> > > >
> > > > Cheerio,
> > > > 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
> > > >
> > > > ___
> > > > 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
> > >
>
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044
> Besancon, France
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Google Summer of Code: We're in!

[Carles Fernandez]

Congratulations for the acceptance in GSoC! I'm happy to announce that
GNSS-SDR (an open source GNSS receiver based on GNU Radio) has been also
accepted as well as a mentoring organization this year:
http://www.google-melange.com/gsoc/org/google/gsoc2013/gnss_sdr

Students: get ready to have fun this summer! :-)

Best regards,
Carles




On Tue, Apr 9, 2013 at 2:15 AM, Tom Rondeau  wrote:

> Nice work, Martin.
>
> Tom
>
>
>
> On Mon, Apr 8, 2013 at 5:36 PM, Martin Braun (CEL) 
> wrote:
> > Hi everyone!
> >
> > I'm happy to say we've been accepted for GSoC 2013!
> >
> > Our GSoC page is up and running at
> > http://www.google-melange.com/gsoc/org/google/gsoc2013/gnuradio.
> >
> > We'll be adding details soon. Students, how about making some $$$
> > writing code for the community? Check out our ideas page.
> >
> > Cheerio,
> > 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
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Updating to 3.7/next (currently)

[Carles Fernandez]

Thanks, Tom and Johnathan for the feedback. We understand that you are
doing your best effort to bring the new release ASAP, and we appreciate
this new organization of the source code; it makes our code clearer and
avoids unnecessary dependencies. The transition using the master/next
branches is quite clean and easy to catch on to, and we can live with the
occasional breaks (at least for a few weeks :-)) since it's all for a
better endeavor.

Best regards,
Carles





On Wed, Apr 3, 2013 at 5:20 PM, Johnathan Corgan
wrote:

> On Wed, Apr 3, 2013 at 2:51 AM, Carles Fernandez
>  wrote:
>
> > Thanks Tom for keeping us updated about the required changes for C++
> > applications that builds against GNU Radio. We are working to adapt our
> code
> > from 3.6 to 3.7 API, and these advices save us a nice amount of time.
> Let me
> > say that the process is running quite smoothly and we are not having big
> > issues in the porting.
>
> Happy to hear that there are no problems.
>
> > Is there a tentative date for releasing 3.7? We are now working with the
> > next branch for adapting our code, but at this moment we should decide
> if we
> > break compatibility with the master branch (3.6 API) in order to go on
> with
> > the required modifications (and asking our users to build the next branch
> > instead of the master, at least until the release of GNU Radio 3.7), or
> just
> > wait for those forthcoming changes.
>
> Our plan is to have the final 3.7 API on the next branch in place very
> quickly, but we haven't set a firm date.  There is one major API
> change left (converting the runtime code to the virtual private
> implementation pattern) to do before then.  This will affect users'
> C++ code in several ways.
>
> First, includes will change in form from these examples:
>
> #include 
> #include 
> #include 
> #include 
>
> ...to:
>
> #include 
> #include 
> #include 
> #include 
>
> Secondly, the C++ classes in the GNU Radio runtime will be accessed
> through the 'gr' namespace, so class declarations that look like:
>
> class my_foo_block : public gr_sync_block {...};
> class my_top_block : public gr_top_block {...};
>
> ...will become:
>
> class my_foo_block : public gr::sync_block {...};
> class my_top_block : public gr::top_block {...};
>
> Finally, creating instances of classes in the runtime will use the
> static class make() function, instead of calling the separate
> gr_make_* calls.  Thus:
>
> gr_make_io_signature(1, 1, sizeof(gr_complex))
>
> ...becomes:
>
> gr::io_signature::make(1, 1, sizeof(gr::complex))
>
> Python and GRC code won't be affected by this change.
>
> It's been a very long time in coming, but once we get this final
> change in place, the remaining work for 3.7 is bug fixing, doc
> cleanup, and having release candidate testing until we're convinced
> that it is stable enough to become the new master.  We'll be
> documenting the process of porting existing code from 3.6 to 3.7 on
> the wiki (Tom has already started this).  Fortunately, it's almost all
> mechanical in nature like the above, and can largely be automated with
> tools like sed.
>
> The 3.6 -> 3.7 change has been a grand internal refactoring while most
> major new features have happened in parallel (without breaking user
> code) on the 3.6 release series.  It's been increasingly difficult to
> maintain these consistent with each other, so Tom and I have a strong
> motivation to get this done as quickly as possible.
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Updating to 3.7/next (currently)

[Carles Fernandez]

Thanks Tom for keeping us updated about the required changes for C++
applications that builds against GNU Radio. We are working to adapt our
code from 3.6 to 3.7 API, and these advices save us a nice amount of time.
Let me say that the process is running quite smoothly and we are not having
big issues in the porting.

Is there a tentative date for releasing 3.7? We are now working with the
next branch for adapting our code, but at this moment we should decide if
we break compatibility with the master branch (3.6 API) in order to go on
with the required modifications (and asking our users to build the next
branch instead of the master, at least until the release of GNU Radio 3.7),
or just wait for those forthcoming changes.

Best regards,
Carles



On Wed, Apr 3, 2013 at 3:59 AM, Tom Rondeau  wrote:

> Hi everyone,
>
> Because of the large diff between 3.6 and 3.7, there's going to be a
> lot of breakage happening with code when moving to 3.7. Luckily, most
> of these changes are simple syntax related edits, like in Python to
> move from almost everything being in the gr module to other modules
> like blocks, analog, digital, etc.
>
> With the changes just recently posted to the next branch, we are now
> changing things that will break external code that compiles against
> GNU Radio. This is the first pass and there will be other changes to
> come. If you are tracking our next branch, here are a few things to
> keep in mind when building against GNU Radio:
>
> * Remove FindGnuradioCore.cmake and FindGruel.cmake,
>Replace with FindGnuradioRuntime.cmake
>
> * Remove all GRUEL_ references and replace GNURADIO_CORE variables
> with GNURADIO_RUNTIME_
>
> * Update #include to 
>
> * Change %include "gnuradio.i" to %include "runtime_swig.i"
>
> There are other changes required that have been discussed in the past.
> This just represents the most recent updates and how to work with
> them.
>
> Thanks,
> Tom
>
> ___
> 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] Academic Papers Formatting

[Carles Fernandez]

Thanks Michael for tidying up the Academic Papers page. I like the format
since it allows quick identification of the papers from each institution,
which tend to be related.

Best regards,
Carles



On Tue, Apr 2, 2013 at 5:23 PM, Michael Dickens  wrote:

> There is quite a nice collection of GNU Radio and SDR papers and related
> links accumulating on this page!  This is great for both GNU Radio, and SDR
> in general.
>
> I see that some links are out of date now and no long available.  Although
> it's good to have them as general references (which one can probably find
> via a quick internet search), it would be even better if they worked from
> this page.  Hence, if you and/or your group has entries on this page, I
> encourage you to check them every so often and keep them up to date (now is
> as good as time as any :).
>
> A number of entries are using the following format, which I just used for
> the UND entries I just added:
>
> {{{
> h4 Your School Name
>
> "Your School Name":http-link-to-your-school
> "Your Department":http-link-to-department
>
> * Author(s), ""Title":http-link-to-document", specific info including
> publication year.
> }}}
>
> and then repeat "* Author(s)..." as needed; and/or add more departments,
> your business name, and so forth.  If you want to link in your specific WWW
> area to your name, feel free to do so.
>
> I would encourage folks to use the above formatting, since it provides all
> of the information necessary to both have the entry look nice as well as
> work correctly.  I also encourage you to "Preview" your changes before
> committing them, to make sure they look nice as well as work correctly no
> matter what formatting you choose to use.
>
> All of the above said, just getting the entries into this page is more
> important than formatting.  As I stated already, if the entry is there one
> can, with a high rate of success, do an internet search to find the
> document.
>
> Keep up the great work, and remember to link it in! - MLD
>
>
> ___
> 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] macport switching between gnuradio and gnuradio-devel ports with installed gr-osmosdr?

[Carles Fernandez]

Hi Michael,

thank you very much for your great job with the gnuradio* and gr-osmosdr
stuff in Macports, even keeping us updated about the progress! Just a
comment: I've found that the gnuradio-next @3.7.0_20130326_0+python27+uhd
build fails in my system. It didn't happen with previous versions. It's a
dwarf in my computer, or someone else has experienced the same? Do I better
wait for that forthcoming release?

Best regards,
Carles



On Mon, Apr 1, 2013 at 6:16 PM, Michael Dickens  wrote:

> This is taking longer than I expected, because I have to modify something
> other than the Portfile in order to get the functionality I need.  I have
> to run that change past "the MacPorts powers that be"; they are usually
> pretty responsive, usually within a day or so.  I'll post back when the
> change is in place. - MLD
>
> On Apr 1, 2013, at 8:54 AM, Michael Dickens  wrote:
> > You're (all) welcome for the gr-osmosdr port.  Seems like it is pretty
> well used as well as kept up, and so is a good candidate for being in
> MacPorts.  That's a great suggestion!  I'm doing a "port selfupdate" right
> now to get the latest of everything, and when that is done I will fix this
> issue.  I'll post back here when it's ready; should be later this morning
> (US/ET).
>
> ___
> 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] Google Summer of Code 2013

[Carles Fernandez]

Hi there,

I would like to ask you about the participation in GSoC 2013 of the
GNSS-SDR project under the umbrella of GNU Radio. Last year I served as a
mentor and we all (the student, other developers and I) had a nice
experience adding Galileo capabilities to the GNSS software receiver. We
enjoyed it, benefited from it, and I would love to participate again in
this year's edition, but I personally feel that only GNSS-SDR took
advantage from the work done in GSoC 2012, having no impact for the
majority of GNU Radio users.

GNSS-SDR is an open source Global Navigation Satellite System software
receiver written in C++ that uses GNU Radio's scheduler, block hierarchy
and some processing blocks. In that sense, we are *users* of GNU Radio but
we do not contribute directly to the project. Since I'm aware that the
slots are limited, I understand that developing other features for general
GNU Radio usage (e.g. the Great Documentation proposal) can have a wider
impact and more people can benefit from it.

Otherwise, if you feel that having third-party applications based on GNU
Radio is positive to the project, I will immediately rewrite the
description at http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC with
new (and hopefully cool) proposals for this summer :-)

Best regards,
Carles



On Wed, Feb 27, 2013 at 8:04 PM, Philip Balister wrote:

> On 02/27/2013 10:49 AM, Dan CaJacob wrote:
> > Really great documentation would be nice.  I know that it has been
> > improving, but maybe GSOC is an excuse for a sprint?  Ideally, the
> > documenter is someone who really knows DSP and what is going on behind
> the
> > curtains.
>
> GSoC is for code related work, not documentation work.
>
> However, a proposal to write some code that would improve usability
> should be OK.
>
> Philip
>
> >
> > References to examples in the documentation would help out immensely.  I
> > often resort to hunting down a block's source code or other blocks and
> > examples that use the block to understand it.
> >
> > I have always wanted an auto-magically generated list of references to
> > other blocks/examples that use the block being documented.  I think this
> > would be easy to do in python.  When building the docs, a script could
> > search for instances of each block in other blocks and examples, then
> > insert them as references in the block's documentation.
> >
> > As someone with little DSP backrground, I would like to be able to see
> some
> > great documentation when I open up a block in GRC or introspect it in
> > python.
> >
> > Very Respectfully,
> >
> > Dan CaJacob
> >
> > -- This email contains sensitive proprietary and confidential
> information.
> > The technical data contained herein is/may be controlled under the U.S.
> > International Traffic in Arms Regulations (ITAR) and may not be exported
> to
> > a Foreign Person, either in the U.S. or abroad, without the proper
> > authorization by the U.S. Department of State. --
> >
> >
> > On Wed, Feb 27, 2013 at 12:39 PM, Martin Braun (CEL)
> > wrote:
> >
> >> Ideas, ideas, ideas!
> >>
> >> Everyone, we need ideas.
> >> The GSoC application deadline is coming closer, and we still are lacking
> >> some ideas.
> >>
> >> So what cool feature of GNU Radio are *you* missing?
> >>
> >> Head over here, and write them down:
> >> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC
> >>
> >> At this point, any random idea is OK. Also, you're not signing up for
> >> anything if you post an idea.
> >>
> >> 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
> >>
> >> ___
> >> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Using MacPorts

[Carles Fernandez]

Relieved to hear that. I've been struggling with clang and volk for a long
time with no success. I learned a lot in the process, though :-)


On Thu, Nov 22, 2012 at 7:25 PM, Johnathan Corgan
wrote:

> On Thu, Nov 22, 2012 at 10:20 AM, Carles Fernandez <
> carles.fernan...@gmail.com> wrote:
>
>
>> I'm happier than a kid in a candy store :-)
>>
>
> GNU Radio does that sometimes.  We've been trying to track down the bug
> but it has eluded us for years :)
>
> Johnathan
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Using MacPorts

[Carles Fernandez]

Hi all,

I've tried (in Mac OS X 10.8.2, Xcode 4.5.2 with up-to-date Command Line
Tools):

$ sudo port install gnuradio +grc +python27 +uhd +orc +swig
configure.compiler=llvm-gcc-4.2

Everything built smoothly. Now when I do volk_profile, the sse
implementations are there and accelerate some volk instructions
considerably. I'm happier than a kid in a candy store :-)

Carles


On Thu, Nov 22, 2012 at 3:26 AM, Michael Dickens  wrote:

> Hi Carles - Thanks for the report; I'm glad it works for you!  If you
> installed the "gnuradio" port using XCode 4.5 or newer (maybe even 4.4 or
> newer), then Apple's Clang is the default compiler suite.  IIRC, Volk and
> Clang do not play nicely together yet; Volk (at least as of the 3.6.2
> release) will enable SSE and related instructions when compiled using gcc
> only.  Which you can do if you want to IIRC by appending
> "configure.compiler=apple-gcc-4.2" to the end of your "sudo port install …"
> command line. Or, you could choose "llvm-gcc-4.2" instead which should also
> work.  I haven't tried either of these yet, so if you do I'd love to hear
> about what happens. - MLD
>
> On Nov 21, 2012, at 6:24 PM, Carles Fernandez 
> wrote:
>
> > I've just tried the variants:
> >
> > sudo port install gnuradio +grc +python27 +uhd +orc +swig
> >
> > and everything seems to work fine, including gnuradio-companion (which I
> lost in Mac OS for ages). Thanks Michael for this great job!
> >
> > Just a question: when I ran volk_profile, I notice that only generic and
> some orc implementations are available, with lots of 'no architectures to
> test'. Does someone has achieved to use sse3 implementations in Mac OS?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Using MacPorts

[Carles Fernandez]

Hi there,

I've just tried the variants:

sudo port install gnuradio +grc +python27 +uhd +orc +swig

and everything seems to work fine, including gnuradio-companion (which I
lost in Mac OS for ages). Thanks Michael for this great job!

Just a question: when I ran volk_profile, I notice that only generic and
some orc implementations are available, with lots of 'no architectures to
test'. Does someone has achieved to use sse3 implementations in Mac OS?

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

Re: [Discuss-gnuradio] Profiling GNU Radio flow graphs

[Carles Fernandez]

Hi Felix,

we have some notes on code profiling here:
http://gnss-sdr.org/documentation/how-profile-code

We use the tools described there in a C++-only flowgraph, but I hope
some of them will also work for you.

Best regards,
Carles




On Fri, Aug 24, 2012 at 8:28 AM, Qing Yang  wrote:
> Hi Felix,
>
> Currently I also need to profile and optimize my system. Now I just add some
> some sentences to print the processing time of each block, but this is
> definitely not a good method. Could you describe your profiling method in
> more details, perhaps your results can be a reference for me.
>
> Hi Tim,
>
> Have you tried this Kcachegrind on GNU Radio flow graphs? Does it works
> well? I want to see the profile of each gr module (in python).
>
>
> --
> Yang, Qing
> Information Engineering, CUHK
>
>
>
> 2012/8/24 
>
>> Hi all,
>>
>> I am currently trying to optimize the performance of my DRM transmitter
>> and for this purpose I want to profile my flow graphs.
>>
>> After some googling and searching the archives I stumbled upon oprofile
>> which looks quite nice to me. However, a first try did not really provide
>> very significant results. But that could also be due to misconfiguration,
>> I did not read the manual very carefully...
>>
>> Just wanted to know if there are other/better solutions for profiling you
>> would recommend. Any comments are appreciated!
>>
>> Best regards,
>> Felix
>>
>>
>> ___
>> 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] How to use VOLK instructions with shorts

[Carles Fernandez]

Dear all,

we are looking into the implementation of correlators in which the two
sequences to correlate are vectors of std::complex. For
gr_complex, we use:

 volk_32fc_x2_dot_prod_32fc_a

but for shorts we would need something like
volk_16ic_x2_dot_prod_16ic_a, which does not exist. What is the best
way to go? It makes sense to implement such a function, or there is
not much gain expected with this specific data format?

Any advice will be greatly appreciated!

Best regards,
Carles

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

Re: [Discuss-gnuradio] GSoc: Filter Desgin Enhancements Intro

[Carles Fernandez]

Dear Sreeraj,

congratulations for the acceptance of your proposal, and thanks for
introducing yourself to the community with this email. We wish you the
best in this adventure!

Best regards,
Carles


On Tue, Apr 24, 2012 at 4:16 PM, sreeraj r  wrote:
> Hi all,
>
> I am Sreeraj and I am currently doing masters in Communication and Signal
> Processing at IIT Bombay, India. First of all thank you all for accepting my
> proposal for improving filter design components in GNU Radio. I have been
> using GNU Radio for quite a while and I am very happy to contribute to this
> project.
>
> The proposed deliverables during GSoC period are given below
>
> QA tests for gr_remez and optfir module
> IIR filter design module and QA tests for this new module
> Improved GUI to incorporate newly designed module and additional features
> like pole-zero plots for IIR filters, filter time responses etc
>
> More detailed plan and schedule can be found here
> https://github.com/zeroXzero/gsoc_proposals/blob/master/filter_enhancements.pdf.
>
> I have created two repositories in github so that the community can track my
> work and comment on the added code which will really enhance my learning
> experience.
>
> 1. gnuradio-gsoc: git://github.com/zeroXzero/gnuradio-gsoc.git -- will
> contain newly added code and discussions during GSoC period.
>
> 2. gnuradio-rsreeraj: git://github.com/zeroXzero/gnuradio-rsreeraj.git --
> Made by following 'DevelopingWithGit' tutorial
>
> I will keep the community posted when some commentable milestones are
> achieved. Expecting good support from all of you.
>
> ---
> Regards
> Sreeraj Rajendran
> http://home.iitb.ac.in/~rsreeraj
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

Re: [Discuss-gnuradio] GR 3.5.1 & OSX

[Carles Fernandez]

Thanks for the hint. It seems that there is a problem with the
libfreetype library:

$  python
Python 2.7.2 (default, Jan 21 2012, 15:35:05)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py",
line 40, in 
from gtk import _gtk
ImportError: 
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/_gtk.so,
2): Library not loaded: /opt/local/lib/libfreetype.6.dylib
  Referenced from:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/_gtk.so
  Reason: Incompatible library version: _gtk.so requires version
15.0.0 or later, but libfreetype.6.dylib provides version 14.0.0

I will try to fix this.  I will post the solution in case of success,
maybe can be useful to others.

Best regards,
Carles



On Sun, Mar 4, 2012 at 4:58 AM, Michael Dickens  wrote:
> Hmm ... not sure what's going on.  When you're in Python, can you do "import 
> gtk" successfully?  That's what CMake is testing for, roughly.  If it can't, 
> hopefully the error will shed some light as to what's going on. - MLD
>
> On Mar 3, 2012, at 9:16 PM, Carles Fernandez wrote:
>
>> Well, actually I had the gnuradio port already and I did a "sudo port
>> uninstall gnuradio" before all the building process. I saw that I have
>> py27-gtk installed but python version is 2.6.7...so I did:
>>
>> $ sudo port select python python27
>> $ python -V
>> Python 2.7.2
>>
>> but when I do
>>
>> $ cmake ../
>>
>> I stiil get
>>
>> -- Configuring gnuradio-companion support...
>> --   Dependency ENABLE_GR_CORE = ON
>> --   Dependency ENABLE_PYTHON = ON
>> --   Dependency PYTHON_MIN_VER_FOUND = TRUE
>> --   Dependency CHEETAH_FOUND = TRUE
>> --   Dependency LXML_FOUND = TRUE
>> --   Dependency PYGTK_FOUND = FALSE
>> --   Dependency NUMPY_FOUND = TRUE
>> --   Disabling gnuradio-companion support.
>>
>>
>> Is there any step I'm missing?
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] GR 3.5.1 & OSX

[Carles Fernandez]

Well, actually I had the gnuradio port already and I did a "sudo port
uninstall gnuradio" before all the building process. I saw that I have
py27-gtk installed but python version is 2.6.7...so I did:

$ sudo port select python python27
$ python -V
Python 2.7.2

but when I do

$ cmake ../

I stiil get

-- Configuring gnuradio-companion support...
--   Dependency ENABLE_GR_CORE = ON
--   Dependency ENABLE_PYTHON = ON
--   Dependency PYTHON_MIN_VER_FOUND = TRUE
--   Dependency CHEETAH_FOUND = TRUE
--   Dependency LXML_FOUND = TRUE
--   Dependency PYGTK_FOUND = FALSE
--   Dependency NUMPY_FOUND = TRUE
--   Disabling gnuradio-companion support.


Is there any step I'm missing?

Thanks,
Carles






Thanks,
Carles

On Sun, Mar 4, 2012 at 2:40 AM, Michael Dickens  wrote:
> Did you use MacPorts for the background dependencies?  If so, you can install 
> one of the py*-pygtk, e.g., "sudo port install py27-gtk" for Python 2.7 
> (which is what I use).  I find that on OSX, Python 2.6 play nice with GNU 
> Radio or GRC, but 2.7 does; YMMV. - MLD
>
> On Mar 3, 2012, at 7:41 PM, Carles Fernandez wrote:
>
>> On Sun, Mar 4, 2012 at 12:22 AM, Michael Dickens  wrote:
>>> Hi Carles - That's great to hear!  I take it that you don't have WX 
>>> installed?  Using the QtGui really is nicer anyway :)  But, having 
>>> gnuradio-companion is also nice ... maybe there is some other dependency 
>>> that isn't getting met for GRC? - MLD
>>>
>>
>> Yes:
>>
>> $ cmake ../
>>
>> ...
>> -- Python checking for pygtk >= 2.10.0
>> -- Python checking for pygtk >= 2.10.0 - not found
>> ...
>>
>> -- Configuring gnuradio-companion support...
>> --   Dependency ENABLE_GR_CORE = ON
>> --   Dependency ENABLE_PYTHON = ON
>> --   Dependency PYTHON_MIN_VER_FOUND = TRUE
>> --   Dependency CHEETAH_FOUND = TRUE
>> --   Dependency LXML_FOUND = TRUE
>> --   Dependency PYGTK_FOUND = FALSE
>> --   Dependency NUMPY_FOUND = TRUE
>> --   Disabling gnuradio-companion support.
>> --   Override with -DENABLE_GRC=ON/OFF
>> ...
>>
>>
>>
>> Does anybody know how to install pygtk in Mac OS? I'd love to use
>> gnuradio-companion...
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] GR 3.5.1 & OSX

[Carles Fernandez]

On Sun, Mar 4, 2012 at 12:22 AM, Michael Dickens  wrote:
> Hi Carles - That's great to hear!  I take it that you don't have WX 
> installed?  Using the QtGui really is nicer anyway :)  But, having 
> gnuradio-companion is also nice ... maybe there is some other dependency that 
> isn't getting met for GRC? - MLD
>

Yes:

$ cmake ../

...
-- Python checking for pygtk >= 2.10.0
-- Python checking for pygtk >= 2.10.0 - not found
...

-- Configuring gnuradio-companion support...
--   Dependency ENABLE_GR_CORE = ON
--   Dependency ENABLE_PYTHON = ON
--   Dependency PYTHON_MIN_VER_FOUND = TRUE
--   Dependency CHEETAH_FOUND = TRUE
--   Dependency LXML_FOUND = TRUE
--   Dependency PYGTK_FOUND = FALSE
--   Dependency NUMPY_FOUND = TRUE
--   Disabling gnuradio-companion support.
--   Override with -DENABLE_GRC=ON/OFF
...



Does anybody know how to install pygtk in Mac OS? I'd love to use
gnuradio-companion...

Best regards,
Carles

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

Re: [Discuss-gnuradio] GR 3.5.1 & OSX

[Carles Fernandez]

Hi guys,

On OSX 10.6.8 I did the following:


$ git clone git://code.ettus.com/ettus/uhd.git
$ cd uhd
$ mkdir build
$ cd build
$ cmake ../
$ make
$ sudo make install
$ cd..
$ git clone git://gnuradio.org/gnuradio
$ cd gnuradio
$ mkdir build
$ cd build cmake ../

...
-- ##
-- # Gnuradio enabled components
-- ##
--   * python-support
--   * testing-support
--   * volk
--   * doxygen
--   * gruel
--   * gnuradio-core
--   * gr-atsc
--   * gr-audio
--   * gr-digital
--   * gr-noaa
--   * gr-pager
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-utils
--   * gr-video-sdl
--   * gr-vocoder
--
-- ##
-- # Gnuradio disabled components
-- ##
--   * gnuradio-companion
--   * gr-comedi
--   * gr-shd
--   * gr-wxgui
--
-- Using install prefix: /usr/local
-- Building for version: v3.5.1-196-g4f0add17 / 3.5.2git
-- Configuring done
-- Generating done
...

$ make
$ sudo make install



It seems that worked! :-)

Best regards,
Carles



On Fri, Mar 2, 2012 at 3:45 PM, Michael Dickens  wrote:
> On Mar 2, 2012, at 9:39 AM, Arturo Rinaldi wrote:
>> can i build the master git branch on macos X 10.7.3 with cmake ? have i to 
>> satisfy the build pre-requisites with macports as usual ?
>
> Hi Arturo - I believe that if you use MacPorts to install the background 
> dependencies -- just do "sudo port install gnuradio", and then, hours later, 
> you can remove the installed GNU Radio / usrp ports, if any actually got 
> installed.  You'll need to install CMake too, since the current GR ports 
> still use GNU Autotools.  You should then be able to use CMake to build GNU 
> Radio from the GIT master on OSX 10.7.3.  I'm still using 10.6.8, but I know 
> others who've used 10.7 and had success.  Getting the dependencies to install 
> is the tricky part, as always :)  Give it a whirl, good luck, and please do 
> let me/the list know if you have issues. - MLD
>
>
> ___
> 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

[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

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

[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 :-)
>>>
>>>
>>>
>&g

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

[Carles Fernandez]

Hi all,

We are using 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
-- Performing Test have_mmmx - Success
-- Performing Test have_msse
-- Performing Test have_msse - Success
-- Performing Test have_msse2
-- Performing Test have_msse2 - Success
-- orc overruled
-- Performing Test have_msse3
-- Performing Test have_msse3 - Success
-- Performing Test have_mssse3
-- Performing Test have_mssse3 - Success
-- Performing Test have_msse4a
-- Performing Test have_msse4a - Success
-- Performing Test have_msse4.1
-- Performing Test have_msse4.1 - Success
-- Performing Test have_mavx
-- Performing Test have_mavx - Failed
-- Available arches:
generic;64;3dnow;abm;mmx;sse;sse2;sse3;ssse3;sse4_a;sse4_1;sse4_2
-- Available machines: generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_1_64
-- Did not find liborc and orcc, disabling orc support...
-- Using install prefix: /usr/local
-- Configuring done
-- Generating done


Tests output:



Running 77 test cases...
Using Volk machine: sse4_1_64
RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
sse4_1 completed in 1.5e-05s
sse completed in 5.5e-05s
generic completed in 1.4e-05s
Best arch: generic
RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i_a
ssse3 completed in 7e-06s
generic completed in 8e-06s
Best arch: ssse3
RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a
ssse3 completed in 1.7e-05s
sse2 completed in 1.1e-05s
generic completed in 2.1e-05s
Best arch:

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

[Carles Fernandez]

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
-- Performing Test have_mmmx - Success
-- Performing Test have_msse
-- Performing Test have_msse - Success
-- Performing Test have_msse2
-- Performing Test have_msse2 - Success
-- orc overruled
-- Performing Test have_msse3
-- Performing Test have_msse3 - Success
-- Performing Test have_mssse3
-- Performing Test have_mssse3 - Success
-- Performing Test have_msse4a
-- Performing Test have_msse4a - Success
-- Performing Test have_msse4.1
-- Performing Test have_msse4.1 - Success
-- Performing Test have_mavx
-- Performing Test have_mavx - Failed
-- Available arches:
generic;64;3dnow;abm;mmx;sse;sse2;sse3;ssse3;sse4_a;sse4_1;sse4_2
-- Available machines: generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_1_64
-- Did not find liborc and orcc, disabling orc support...
-- Using install prefix: /usr/local
-- Configuring done
-- Generating done


Tests output:



Running 77 test cases...
Using Volk machine: sse4_1_64
RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
sse4_1 completed in 1.5e-05s
sse completed in 5.5e-05s
generic completed in 1.4e-05s
Best arch: generic
RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i_a
ssse3 completed in 7e-06s
generic completed in 8e-06s
Best arch: ssse3
RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a
ssse3 completed in 1.7e-05s
sse2 completed in 1.1e-05s
generic completed in 2.1e-05s
Bes

Re: [Discuss-gnuradio] Large FFTs

[Carles Fernandez]

On Tue, Aug 24, 2010 at 1:02 AM, Thomas Hobiger  wrote:
> Hi Carles,
>
> Thanks for the reply. That's a very helpful comment.
>
>> we have found some problems when using USRP2+DBSRX for GPS due to
>> phase noise. See details in http://www.ruby-forum.com/topic/213845
>>
>
> Once we have the components in the lab, I am going to play with them, having
> your comment on my check-list.
>>
>> If someone have succeded on this, we would appreciate some hints to
>> make it work. Our software GPS receiver was not able to track signals,
>> while it run smoothly when using USRP1 + DBSRX without modification.
>>
>
> By tracking signals, do you mean that one of the receiver loops (DLL, PLL)
> lost lock or does it only prevent to extract the navigation bits?
>

I mean that the PLL lost lock after a few seconds, so we were able to
extract only a few (and useless) navigation bits. We played with the
filter loop, without success for the moment. We are quite confident in
the software receiver, it works nice with other hardware
configurations, and that is why we suspect that it could be a hardware
issue. We will be working on this in the next month. I will let you
know our advaces.

Best regards,
Carles


> Best regards,
>  Thomas Hobiger
>
>
>
> --
> **
> Dr. Thomas Hobiger
> Space-Time Measurement Project
> Space-Time Standards Group
> New Generation Network Research Center
> National Institute of Information and Communications Technology
> --
> 4-2-1 Nukui-Kitamachi, Koganei
> 184-8795 Tokyo
> Japan
> --
> email:  hobi...@nict.go.jp
> --
> homepage (priv.): http://www.hobiger.org
> **
>
>

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

Re: [Discuss-gnuradio] Large FFTs

[Carles Fernandez]

Dear Thomas,

we have found some problems when using USRP2+DBSRX for GPS due to
phase noise. See details in http://www.ruby-forum.com/topic/213845

If someone have succeded on this, we would appreciate some hints to
make it work. Our software GPS receiver was not able to track signals,
while it run smoothly when using USRP1 + DBSRX without modification.

Best regards,
Carles Fernandez




On Mon, Aug 23, 2010 at 10:00 AM, Thomas Hobiger  wrote:
> We are considering to purchase a USRP2 + a DBSRX board in order to utilize
> it for some GPS stuff. Thus it would be interesting to know what's the
> maximum supported (implemented) FFTs size. I have checked the old
> discussions, but there's nothing really conclusive. What we are looking for
> is something larger than 16K FFT points.
> Maybe someone has experiences with such large FFTs and how they perform
> (Flops or FFTs per second)?
>
> Best regards,
>  Thomas Hobiger
>
> --
> **
> Dr. Thomas Hobiger
> Space-Time Measurement Project
> Space-Time Standards Group
> New Generation Network Research Center
> National Institute of Information and Communications Technology
> --
> 4-2-1 Nukui-Kitamachi, Koganei
> 184-8795 Tokyo
> Japan
> --
> email:  hobi...@nict.go.jp
> --
> homepage (priv.): http://www.hobiger.org
> **
>
>
> ___
> 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

Re: [Discuss-gnuradio] Unable to build gr-wxgui on Mac OS X 10.6.1

[Carles Fernandez]

Hi all,

yes, it works :-) This is what I did in OS X 10.6.4:

sudo port selfupdate
sudo  port upgrade outdated
sudo port install python_select
sudo python_select python26
sudo port install mesa
sudo port clean --all wxWidgets-python
sudo port -d install py26-wxpython
sudo port install gnuradio
export 
PYTHONPATH=/opt/local/lib/python2.6/site-packages:/usr/local/lib/python2.6/site-packages

... and grc is working.

Thanks, folks!
Carles


On Thu, Jul 8, 2010 at 5:43 PM, Michael Dickens  wrote:
> Hi Bruh - Glad to hear you're getting Wx to work for you.  We're working on
> getting the Qt GUI working as well.  I know that the state of Wx on MacPorts
> is "confusing" right now -- to me as well.  If I were you, now that you've
> got it working, I'd leave my MacPorts install alone until the Wx stuff gets
> worked out; could be a long time, and it really depends on how quickly the
> Wx folks get their 32/64 OSX 10.5/10.6 acts together.
>
> To address your question:
>
> On Jul 8, 2010, at 3:50 AM, Bruhtesfa Ebrahim wrote:
>>
>> That did the trick and I now installed gnuradio including gr-wxgui and
>> grc, but got this warning:
>> {{{
>> *** Post-Install Message ***
>> Warning: python could not find the gnuradio module.
>> Make sure that /usr/local/lib/python2.6/site-packages is in your
>> PYTHONPATH
>> }}}
>> I used the "~/.bashrc" file suggested at
>>
>>
>> https://radioware.nd.edu/documentation/install-guides/mac-os-x/preliminaries,
>> where the PYTHONPATH was set to
>>
>> /usr/local/lib/python${PYTHON_VERSION}/site-packages.
>>
>> So, I could not figure out why this happened. Any suggestions?
>
> Assuming you setup your .bashrc file exactly as found in the "Additional
> Login Scripts" section of that page, and MacPorts is fully installed to use
> its own 'python', then the PYTHONPATH should read something like:
>
> PYTHONPATH=/opt/local/lib/python2.6/site-packages:/usr/local/lib/python2.6/site-packages
>
> where the former path is for MacPorts and the latter for GNU Radio.  If all
> you're getting is the PYTHONPATH you list, then I would bet you haven't
> selected (in MacPorts) the correct version of python.  What does "which
> python" return for you?  ditto for "ls -l `which python`" ... if either of
> those shows that the version is "/usr/bin/python" or the like, then you need
> to select the MacPorts' version, via (assuming you're using MacPorts' port
> "python26" as I do):
>
> $ sudo port install python_select
> $ sudo python_select python26
>
> and that should do the trick.  No matter how much automation we build in,
> someone eventually messes with some part of it to require even more :)  Hope
> this help! - MLD
>
> ___
> 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

[Discuss-gnuradio] Gigabit Ethernet chipset

[Carles Fernandez]

Hi,

I would like to ask what chipset is used in the USRP2 for managing the
Gigabit Ethernet interface. I haven't been able to find this
information on the web.

Help will be really appreciated.

Best regards,
Carles.


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

[Discuss-gnuradio] Bug in GRC

[Carles Fernandez]

Small bug in grc:

gnuradio/grc/data/grc_gnuradio/blocks/gr_xor_xx.xml, line 10:

from gnuradio impxort gr

should be:

from gnuradio import gr


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

Re: [Discuss-gnuradio] boost 1.35

[Carles Fernandez]

I followed gnuradio/README.building-boost (from the trunk) and it run
smoothly on Ubuntu 8.04:

Download the latest version of boost from boost.sourceforge.net.
(boost_1_36_0.tar.bz2 was the latest when this was written)

unpack it somewhere
cd into the resulting directory

$ cd boost_1_36_0

# Pick a prefix to install it into.  I used /opt/boost_1_36_0

$ BOOST_PREFIX=/opt/boost_1_36_0

$ ./configure --prefix=$BOOST_PREFIX --with-libraries=thread,date_time
$ make
$ sudo make install

Now, tell gnuradio where to find it:

$ export LD_LIBRARY_PATH=$BOOST_PREFIX/lib

$ cd 
$ ./bootstrap
$ ./configure --with-boost=$BOOST_PREFIX  # plus whatever config args you
usually use

$ make && make check
$ sudo make install



On Fri, Aug 22, 2008 at 12:58 PM, Frank Brickle <[EMAIL PROTECTED]> wrote:

> In /opt/boost_1_36_beta on 8.04 with kernel 2.6.24-21-rt.
>
> ./configure --with-boost=/opt/boost_1_36_beta --enable-doxygen --no-create
> --no-recursion
>
> Frank
>
>
>
>
> On Fri, Aug 22, 2008 at 2:37 AM, Firas A. <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi,
>>
>> Has anyone been able to install boost 1.35 or 1.36 on Ubuntu OS system?
>>
>> Regards,
>>
>>
>> Firas
>> --
>> View this message in context:
>> http://www.nabble.com/boost-1.35-tp19100103p19104236.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> All who think cannot but see there is a sanction like that of religion
> which binds us in partnership in the serious work of the world. -- B.
> Franklin
>
> ___
> 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

[Discuss-gnuradio] Problem updating wx

[Carles Fernandez]

Hi,
I just have updated wxWidgets and wxPython packages as explained at
http://wiki.wxpython.org/InstallingOnUbuntuOrDebian

1) Add repositories to /etc/apt/sources.list:

deb http://apt.wxwidgets.org/ hardy-wx main
deb-src http://apt.wxwidgets.org/ hardy-wx main

2) Update package meta-data:  sudo apt-get update

3) Update packages: sudo apt-get install python-wxgtk2.8 python-wxtools
python-wxaddons wx2.8-i18n

Then, in the gnuradio home directory:

svn update
./bootstrap
./configure --with-boost=/opt/boost_1_36_0 --enable-all-components
--disable-gr-gcell --disable-gr-audio-osx --disable-gr-audio-windows
--disable-gr-audio-oss --disable-gcell --disable-gr-audio-jack
--disable-gr-audio-portaudio --disable-gr-comedi

I get:

...
Component gr-radio-astronomy passed configuration checks; building.
Component gr-trellis passed configuration checks; building.
checking for SDL... yes
Component gr-video-sdl passed configuration checks; building.
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named wx
configure: error: Component gr-wxgui has errors; stopping.



What I have to do for importing the wx module again?

Thanks!

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

Re: [Discuss-gnuradio] GPS L2C transmissions?

[Carles Fernandez]

Maybe little bit off-topic in this list, but any of you have tried gpstk (
http://www.gpstk.org/bin/view/Documentation/WebHome)?

I'm trying to use it in combination with gps-sdr. I'll keep you updated on
my progress!

BR,
Carles




On Sun, Aug 10, 2008 at 4:55 AM, Peter Monta <[EMAIL PROTECTED]> wrote:

>
>  From my knowledge all the semi-codeless tracking algorithms are heavily
>> patented, and hence cannot be found in textbooks or in any open forum.
>>
>>
> But the patents themselves contain pretty good descriptions of the
> techniques;
> also there is this paper:
>
>
> http://www.navcomtech.com/Support/Download/Optimum%20Semi-Codeless%20Carrier%20Phase%20Tracking%20of%20L2.pdf
>
> which summarizes all the options and adds a soft-decision refinement to
> Z-tracking.  Some of the patents will expire pretty soon, probably before
> L2C is fully usable.
>
> There ought to be a fully open-source, geodetic-quality, dual-frequency (or
> tri-frequency once we have L5, or quad- or quint-frequency once we have
> Galileo and Glonass and accurate IGS orbits and clock ties for these other
> GNSS systems), software receiver.  I have no real connection with any of
> this (just a hobbyist), but I'd enjoy having access to state-of-the-art
> timing
> and survey solutions.
>
> Finally snagged a dual-frequency antenna on Ebay a few weeks ago, so
> only software sits between me and centimeter positioning and subnanosecond
> UTC (or UTC(GPS) or UTC(IGS) anyway).
>
>
> Cheers,
> Peter
>
>
>
> ___
> 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

Re: [Discuss-gnuradio] GPS L2C transmissions?

[Carles Fernandez]

Hi Peter,

maybe you could be interested on this: at www.gps-sdr.com there is a C
driver for the USRP that manages a couple of DBSRX daughterboards, one
centered at L1 and the other one at L2, just what you are mentioning for
building a dual-frequency GPS software receiver.

Cheers,
Carles.



On Fri, Aug 8, 2008 at 4:53 PM, Peter Monta <[EMAIL PROTECTED]> wrote:

> On the chance that there are GPS folks here that are
> familiar with the status of the new L2C signals:  is there
> a currently-maintained list of which satellite is emitting
> what?  In particular, PRN 29 seems to have no L2C (or
> at least none that I can acquire), while PRN 31 has a nice
> strong carrier (tracked with L2CM) but no NAV or CNAV data
> modulation---it's apparently sending only carrier.  I'd
> like to find a signal with CNAV data.
>
> While I haven't tried it yet, the USRP should be capable
> of saving to disk both L1 and L2C using a pair of dbsrx
> daughtercards.  That should permit dual-frequency
> receiver software.  It would be nice to have a
> waveform-pair-to-RINEX tool to allow use of the various
> web services for dual-frequency solutions.
>
> Cheers,
> Peter
>
>
>
> ___
> 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

Re: [Discuss-gnuradio] 64MHz USRP Oscillator

[Carles Fernandez]

By the way, could someone tell me what is the part number of the VCTCXO
shipped with USRP Rev 4.5? In the bill of materials of the trunk I see
"CTX286LVCT-ND", which seems to correspond to CB3LV-3C-64M in the
manufacturer's nomenclature.

The datasheet (http://www.ctscorp.com/components/Datasheets/008-0256-0_E.pdf)
specifies +/- 50 ppm, but I have read somewhere that actually it is +/- 20
ppm.

Which is the right one?

Thanks,
Carles.




> >>> <[EMAIL PROTECTED]> wrote:
> >>> > Hi All,
> >>> >
> >>> > I am having lots of issues with the USRP  64MHz (20ppm) on board
> >>> > oscillator
> >>> > which does not allow me to get exact and constant RF frequencies out
> of
> >>> > the
> >>> > RFX900 board. I can not really fix that in SW so I was thinking about
> >>> > replacing the 64MHz crystal with a more precise one. Has anybody a
> >>> > suggestion of which part to use?
> >>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Documentation

[Carles Fernandez]

I offer my pair of hands to the round of applause. Thank you, Firas!!



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

Re: [Discuss-gnuradio] DAB with GNU Radio

[Carles Fernandez]

Hi Andreas,

I am also interested in your work. Would you be so kind of sending me your
thesis when it is finished?

Thanks a lot!

Best regards,
Carles Fernández.



On Tue, Jun 10, 2008 at 4:01 PM, Andreas Müller <[EMAIL PROTECTED]> wrote:

> Hello Chris
>
> > we would like to implement a DAB receiver with GNU radio. On the
> > hardware side we have a USRP with the TVRX daughterboard.
>
> Jens Elsner, who worked on DAB some time ago, found out that the TVRX
> actually disturbs the OFDM signal very much, making it rather hard to
> receive DAB, so I would strongly discourage its use (I'm not able to get
> any information out of TVRX samples currently).
>
> My current setup involves a spectrum analyzer to receive the signal, and
> an external mixer+signal generator to convert from the IF of the SA down
> to 10 MHz for the BasicRX. I have uploaded some of the samples to [1].
>
>
> If you have a DAB station in the L-Band near you, you can also use the
> DBSRX. (@Jens -> is it ok if I publish your mode 2 samples as well?).
>
> > From some
> > older posts on this list, i learned that there are already some people
> > trying to do this.
>
> I have implemented part of DAB for my current semester thesis. I have a
> working physical layer (all OFDM stuff, all 4 DAB modes complete for
> transmitting and receiving), and enough of the FIC (fast information
> channel) to see the names of the radio stations (receiving+some blocks
> for transmitting; all modes). To actually hear something, the MSC
> (main service channel) would be needed (many blocks in the MSC already
> exist, as they are needed for the FIC too, so it should not be that much
> work).
>
> > Is there any initial advice or pointers to existing implementations you
> > could give us? Do we need the checkout the svn version or even some
> > branch or is the 'latest stable' enough?
> >
>
> I have uploaded my current code to [2]. It requires GNU Radio from the
> trunk and some small patches (mainly for the peak detector). If you are
> interested, I can also send you my mostly-finished semester thesis
> off-list.
>
> I hope to finish the FIC in the next week or so, but as my thesis is
> over at the end of this week, I am not sure, when/if I'll get to the
> MSC. The code for OFDM and FIC currently runs real-time on my four year
> old ThinkPad (Pentium M 1.6 GHz).
>
> Regards, Andreas
>
> [1] 
> http://people.ee.ethz.ch/~andrmuel/files/gnuradio/samples/
> [2] 
> http://people.ee.ethz.ch/~andrmuel/files/gnuradio/gr-dab.tgz
>
>
> ___
> 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

Re: [Discuss-gnuradio] GPS on USRP

[Carles Fernandez]

Hi Faisal,

I'm also working with GNU Radio for GNSS applications. A good start could be
a recording of samples into datafiles and then post-process the data in the
way that you feel more comfortable (the book [1] comes with a DVD with a
complete GPS L1 receiver implemented in MATLAB, all GNU code). Once you get
familiarized with the processing, you can try to implement the receiver in
GNU Radio.

At least, this is the way I'm following. Any suggestion would be welcome.

Cheers,
Carles.

[1] Kai Borre, Dennis M. Akos, Nicolaj Bertelsen, and Peter Rinder, A
Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach
(Applied and Numerical Harmonic Analysis). Birkhäuser Boston; 1 edition
(November 9, 2006)



On Fri, Feb 29, 2008 at 6:45 PM, Paul Creekmore <[EMAIL PROTECTED]> wrote:

>  Faisal,
>
> I'm at Purdue University working toward using the USRP for GNSS
> applications.  Check my understanding: are you wanting to use the USRP to
> record, say, L1 band samples directly to a data file?  Would you be
> performing all of the signal acquisition and tracking in post-processing
> with a separate software tool?
>
> I'm working on Linux (Debian), but we aught to be able to trade notes.  If
> you've got a working installation of GNU Radio, I can show you how to record
> samples.
>
> --Paul
>
> Phaysal Khan wrote:
>
> Hi,
> I am a newbie to USRP, and still struggling to get it working on my
> windows machine. I am trying to use cygwin. I reckon that many ppl have
> already acquired and tracked GPS on USRP. Waht I want to do is to capture
> GPS IF samples (e.g. at IF=5 MHz) and use a software receiver to process
> those IF samples on PC. Any suggestions to start?!...
>
>
>
> Faisal A. Khan
> Doctral Candidate
> University of New South Wales
> NSW 2052, Sydney, Australia
> P) +61-2-93854208M)+61-401-260728
>
>
>
> --
> Join Lavalife for free. What are you waiting 
> for?
>
>
> ___
> 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

Re: [Discuss-gnuradio] Interest in beamforming and GNSS receivers

[Carles Fernandez]

Thank you very much for your informative responses. Now things are clearer
to me: the possibility of building an antenna array combining two or more
USRPs is just exciting! I'm also delighted with the option of using an
external reference clock. I definitely will buy at least one USRP for the
first experiments and the development of a simple GPS receiver. If my
progress is adequate, I will go for the multi-antenna approach.

I will keep you informed, and surely I will come often with new questions.
Thanks again for those great sources of information, I'm really enjoying
while exploring them.

Cheers,
Carles.



On Jan 31, 2008 10:33 PM, Martin Dvh <[EMAIL PROTECTED]> wrote:

> Pavol Ďuriš wrote:
> > Hi all,
> >
> > I have an interest in radioastronomy. I plan to make simple beamforming
> > phase array (primary with 4 and later with 8 antennas) with USRP (later
> > with 2) and GNU Radio. I am inspired by LOFAR radiotelescope.
> > Now I collect all available information about using GNU Radio and USRP
> > for it.
> >
> > Martin, could you send more information about your solution, project
> > (url etc.) ?
>
> Info about connecting murli-USRPs:
>  http://gnuradio.org/trac/wiki/MultiUsrp
>  http://gnuradio.org/trac/wiki/USRPClockingNotes
>
> http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-examples/python/multi_usrp
> This last one is also in your gnuradio source directory:
>  gnuradio-examples/python/multi-usrp
>
> It has been a while since I last used this setup, so there might be some
> bitrot.
> (incompatibilities between the multi-usrp fpga firmware (rbf-file) and the
> latest gnuradio code and support for the latest daughterboards.)
> But if this is the case then it should be solvable by implementing the
> latest changes to the standard USRP firmware to the multi-USRP firmware.
>
>
> There is not much info about my phase-array experiments online.
> I know, I should update my website more often, but I am better at writing
> code then at writing human-readable text.
> I do haver a snapshot of my CMA (Constant Modulus Algorithm) adaptive
> phase-array code.
> This code automatically adapts to multiple FM, GMSK, QPSK or M-PSK
> sources.
> It should be able to extract multiple sources on the same frequency by
> automatically nulling the other sources out when extracting one.
> (max number of sources == number of antenna's used)
>
> Note that this code only works with phase-coherent daughterboards (boards
> which use the USRP-clock as refclock)
> This means allmost all daughterboards except TVRX.
> (Which is too bad since I want to extract multiple broadband FM stations,
> for now I use undersampled basicRX)
> The code is at:
> http://www.olifantasia.com/projects/gnuradio/mdvh/CMA_phase_array/
>
> Other code of mine can be found at:
> http://www.olifantasia.com/projects/gnuradio/mdvh/
> or
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1
> or (when it has stabalized) in GnuRadio trunk
>
> Greetings,
> Martin
>
> > Thanks,
> > Pavol
> >
> > PS: I haven't USRP yet. However, I am buying my first USRP, right now :)
> >
> > Martin Dvh wrote:
> >> Carles Fernandez wrote:
> >>
> >>> How well are they synchronized?
> >>>
> >> They run off the same 64 MHz clock, so are synchronised.
> >> I have even used two connected USRPs running of the same clock (one is
> >> master and exports its clock to the slave USRP)
> >> (You use an additional flatcable between the USRPS and an align
> >> software block in gnuradio which aligns the samples)
> >> This gives you 8 ADCs. This means 8 real channels or 4 complex
> channels.
> >>
> >> I used this setup for a phase array with 4 DBSRX daughterboards.
> >> (DBSX daughterboards use complex sampling so they need two ADCs)
> >> DBSRX boards also support the GPS frequencies and are a lot cheaper,
> >> so you might want to consider them.
> >> But they are receive only.
> >>
> >> You can even go higher and connect 4, 8 or 16 USRPS.
> >>
> >
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Interest in beamforming and GNSS receivers

[Carles Fernandez]

Hi everybody,

I discovered GNU Radio few months ago, in a before-go-to-bed surfing. I
found it very interesting, but complicated because of my poor skills in
programming Python or C++. I'm doing research on Global Navigation Satellite
Systems (GNSS) receivers, and I'm used to code everything in Matlab. Night
after night, I've been browsing the documentation and making humble steps: I
installed Ubuntu on my laptop, followed the -excellent, also for dummies
like me- guide for installing all the software, read diagonally the
documentation and played with sample codes. Some Hello Worlds, some problems
with the audio module, getting used to read the mailing list, feeling
astonished by the intense activity of this community... nothing new, I
guess.

Now I want to take it more seriously. I've seen that both python and c++
have very well done matrix algebra libraries, and that's exactly what I need
for my research (you can call me naive). I would like to implement a GNSS
receiver (in the wide sense) based on an antenna array and play with
beamforming algorithms and weird RF front-end architectures (direct RF, IF
sampling, etc). My main concern is synchronization, concretely I want to
implement some signal processing algorithms in a real receiver in order to
assess their impact in the whole system, testing them with real data. I've
been working in the development of some algorithms that -theoretically-
performs better in multipath environments, but I want to see if this is true
beyond classical academic benchmarks.

What is the state of GNSS receivers development in GNU Radio? I have found
some expressions of interest in the Internet, but nothing concrete. I'm
willing to start it from the scratch, but it is nonsense to reinvent the
wheel. I would like to put in contact with other people interested on these
topics. Taking advantage of your patience, I have some other questions (and
you will see my newbie approach):

- I've seen some statements about "beamforming is possible". To what extend?
I'm trying to understand the multi-antenna code example, but it is possible
to use the four ADC at the same time? How well are they synchronized? it is
possible to compute the weight values in software and perform the
multiplication in the FPGA at real time? There is any other major bottleneck
than algebraic weight computation time?

- My first target is a "traditional" L1 C/A code GPS receiver. I guess that
I can choose between RFX1200 and a BasicRx with an external front-end. Have
someone worked in the connection of GNU Radio with gpstk?

- It is 32 MHz the maximum bandwidth available? Will the USRP 2.0 increase
this bandwidth? It is possible to decrease the resolution of the ADCs and/or
increase their sampling frequency?

- I also would like to work on the Galileo signal structure and the new L2CS
GPS signal, mostly on the correlators. I have a background on signal
processing, but I'm strongly matlab-shaped in what about programming is
concerned. I'm willing to learn, but am I pointing to the right direction?


If someone could enlighten me in some of this questions, it would be greatly
appreciated. Sorry for the long text.


Best regards,
Carles Fernandez
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio