[Discuss-gnuradio] Dev Call August 16th (Friday)

[Martin Braun (CEL)]

Hi everyone,

our next developer's call will be on Friday, August 16th.
This is an *exception* from our third-Thursday rule, in the future, we
will still be sticking to that.

Also, we'll try and reduce the chaos in the hangouts, so we have exactly
one of them (and only one live stream).
I will join the hangout early (say, 5-10 minutes ahead of schedule).
Thus, when you join the hangout and see I'm there, you know you're
in the right spot[1].

Once the hangout is live, Phil or I will post the YouTube link on the
list. This should make it really easy to follow the call for all of
those who just want to listen in.

MB

[1] A common rule-of-thumb for partygoers in the Karlsruhe area :)

-- 
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


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

Re: [Discuss-gnuradio] PMT blobs in Python

[Josh Blum]

On 08/04/2013 06:08 AM, Marcus Müller wrote:
> I can't really test this right now,
> but you could insert
>   %include 
> into your project's swig file[1]; this should generate a python method
>cdata(ptr, length)
> that you can feed your blob_data() to. I'm not quite sure that WILL
> work as is, maybe you will need a C(++) wrapper that simply returns
> an array of known type (that is, int* instead of void*) that you can
> yourself wrap into a SWIG array_class (like in the linked document).
> 

I dont know if this made it into PMT, buts its definitely in gr core for
the block gateway. Basically the snippet gives you a numpy array given a
ptr and length. Once its in numpy, you can shape it however, no copies
involved, do math on it, etc...

Here it is for the blob extensions in the old grextras:
https://github.com/guruofquality/grextras/blob/grextras_v3.6/python/extras_pmt.py#L32

Using a similar one in PMC to handle various numeric arrays:
https://github.com/guruofquality/PMC/blob/master/python/PMC/PMCNumericArray.i#L87

And again for the smart buffer type:
https://github.com/guruofquality/gras/blob/master/include/gras/sbuffer.i#L26

go numpy!

-josh

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

Re: [Discuss-gnuradio] Dynamic number of "message" ports using nports

[Josh Blum]

On 07/29/2013 08:37 AM, macbany wrote:
> I'm using GnuRadio 3.6.5.1 and I wanted to create a block similar to
> stream-to-streams for messages. In the XML I used a variable and nports so I
> could specify the number of ports in the flowgraph. However, I've found that
> this does not work. Whenever I change the variable value to something
> greater than 1, the variable ID turns red and the number of ports displayed
> does not change. Simply changing the port type to something other than
> "message" works correctly. Does anyone have an idea how to fix this?
> 
> 

So I think its sort of fundamental the the message ports cant be scaled
like that because they are named and not linearly indexed. You could
find a way do to it, but its a more invasive GRC change I guess. Perhaps
Martin's GSoC student might consider doing this for the GRC
improvements, if not already?

-josh

> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Dynamic-number-of-message-ports-using-nports-tp42766.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

[Discuss-gnuradio] Announcing new GRAS Feature - Block Factory

[Josh Blum]

Hello list,

As a follow-up to my last announcement "Advanced scheduler pw0ns SWIG
for you" (which I was quite excited about), I have since tried to
formalize the feature-set and document it:

What I am collectively calling the block factory is really:
* A CMake utility to build and install runtime loadable modules
* A system to load runtime modules from the specified paths
* An API to register block constructors into the factory
* An API to create blocks from the factory
* An API to register block methods into the framework
* An API to call into registered methods

That may sound complicated, but actually, all of the complexity is
handled in the guts of the framework. So in contrast, this is probably
the simplest it has even been for a user to create custom blocks. The
CMake projects that build and install a user's blocks are brief and to
the point -- no swig, a minimal number of files. Builds are quick and
snappy and its easy to debug build errors. The registration APIs are
very clean and non-invasive -- as are calling into the registered
factories and class methods. Here is the run-down:

The code guide has example snippets on how to painlessly register block
constructors and methods, and how to call into them at runtime:
https://github.com/guruofquality/gras/wiki/Codeguide#wiki-block-factory

This wiki page lists the pros and the cons of using this feature:
https://github.com/guruofquality/gras/wiki/Blockfactory

The module guide hosts a usable example CMake build project,
and explains in more detail how GRAS finds modules at runtime:
https://github.com/guruofquality/gras/wiki/Moduleguide

I switched every block in GrExtras over to this new system without
exception. Every C++ and CMake file stands as a useful example:
https://github.com/guruofquality/grextras/

Something neat you can do; Here is an example of a block where the same
code takes on a different API depending upon which factory path is used:
https://github.com/guruofquality/grextras/blob/master/math/add_const.cpp#L22

I moved the Clang part of the GrExtras Clang Block into GRAS. The new
jit_factory() call provides the backend for the Clang Block. You can
literally just dump C++ source into this call, from Python, at runtime,
and find your blocks in the factory.
https://github.com/guruofquality/gras/blob/master/include/gras/factory.hpp#L15

Using this set of features doesn't preclude the normal way of making
libraries or python modules. Blocks from a SWIG'd library work just fine
with blocks from a factory. And for that matter, block factories don't
do everything. If a user needs to have a set of utilities to go along
with the blocks, nothing is wrong with building your typical dlls along
with the modules for the block factory. Etc, etc...

I'm very proud of this work. And I think that this feature-set has the
potential to improve a lot of user's experiences. I hope y'all like it too!

-Josh

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

Re: [Discuss-gnuradio] Still problems building gr 3.4.2 / Debian

[Ralph A. Schmid, dk5ras]

It works now. It is a number of traps a newby never could figure out on his
own, but finally it is possible, and even not too complicated when you know
what you need to do. 

 

I had no choice, as I have a relative new tablet PC (Microsoft Surface pro),
and it even was difficult to find a Linux distribution that worked without
too much of a hassle. Many hours during the last weeks and months seem to be
wasted and could have been used for so much interesting SDR experiments, but
now I have a super portable system. As I am traveling a lot, this is very
useful, especially when the long awaited BladeRF finally arrives.

 

With best regards


Ralph.

 

 

From: Christophe Devine [mailto:devinechristo...@gmail.com] 
Sent: Saturday, August 03, 2013 1:33 PM
To: Ralph A. Schmid, dk5ras
Subject: Re: [Discuss-gnuradio] Still problems building gr 3.4.2 / Debian

 

Ralph,

 

I tried the same as you, compiling 3.4.2 on the latest Debian. I gave up,
and went back to Ubuntu 12.04. What you can do is to compile 3.4.2 to obtain
just libusrp on Ubuntu 12.04 (or older), for example using a VM, then move
the libusrp library to your Debian, to enable compilation with OpenBTS. I
haven't tried this in practise though, as I still use 12.04.

 

On Fri, Aug 2, 2013 at 6:27 AM, Ralph A. Schmid, dk5ras 
wrote:

Hi,

After compiling and installing sdcc2.9 from source this problem seems to be
solved, but now building gr 3.4.2 on a Debian / Jessie (testing) AMD64
machine gives right after confirming the sdcc version another error. It says
that it does not find libusb, but in fact the packages are installed, and gr
3.7 uses them just fine.

Any ideas what the reason could be?



--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223  
ra...@schmid.xxx
http://www.bclog.de/




___
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] Help: Constellation Receiver::Object

[tom sutherland]

I am trying to use the Constellation Receiver Block and one of the Parameters 
is "Constellation Object". Is this a pointer to an object and how/what creates 
this object? I have looked at the qam.py file but don't follow how this relates 
to placing a block down in gnuradio companion.
Thanks...Tom

Sent from Yahoo! Mail on Android

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

[Discuss-gnuradio] Public transport in Boston

[Philip Balister]

I am looking at hotels in Boston GR Con. Needless to say, I will never
complain about Si valley rates again.

Does anyone have any comments about public transport in Boston?
Especially about getting from cheaper hotels to the conference location.

Thanks,

Philip

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

Re: [Discuss-gnuradio] Public transport in Boston

[Nowlan, Sean]

I found a Holiday Inn Express along the Red line of the T, maybe 20 mins south, 
for ~215 a night. Haven't placed the order though. Just took a look at avg 
rates on their website.

-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Philip Balister
Sent: Monday, August 05, 2013 11:12 AM
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] Public transport in Boston

I am looking at hotels in Boston GR Con. Needless to say, I will never complain 
about Si valley rates again.

Does anyone have any comments about public transport in Boston?
Especially about getting from cheaper hotels to the conference location.

Thanks,

Philip

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

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

Re: [Discuss-gnuradio] Public transport in Boston

[Nick Foster]

Boston's "T" is a pretty good, reasonably reliable public transit system,
and the city is compact enough that it's generally pretty easy to get
around. The conference is very close to South Station, which is the largest
transport hub in Boston. South Station is on the Red Line of the MBTA
subway and is easy to get to from any other "T" stop with a maximum of 1
transfer.

If you were incredibly, world-class cheap, you could even stay way out in
the suburbs and take the commuter rail into South Station for the
conference. Personally, if I wanted to save money, I'd look out toward
Quincy Adams on the south end of the Red Line for a cheaper place to stay,
and take the Red Line into South Station.

Here's a map showing the subway and commuter rail lines:
http://www.mbta.com/schedules_and_maps/rail/

--n

On Mon, Aug 5, 2013 at 8:12 AM, Philip Balister  wrote:

> I am looking at hotels in Boston GR Con. Needless to say, I will never
> complain about Si valley rates again.
>
> Does anyone have any comments about public transport in Boston?
> Especially about getting from cheaper hotels to the conference location.
>
> Thanks,
>
> Philip
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Public transport in Boston

[Nowlan, Sean]

Also, the train doesn’t go to the airport, but there are frequent bus transfers 
to nearby train stations. I suggest Google Maps or the MBTA website itself. The 
latter provides a Route Planning tool an lets you choose between Google Maps or 
their own interface.

http://www.mbta.com/

--sean

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Nick Foster
Sent: Monday, August 05, 2013 11:40 AM
To: Philip Balister
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Public transport in Boston

Boston's "T" is a pretty good, reasonably reliable public transit system, and 
the city is compact enough that it's generally pretty easy to get around. The 
conference is very close to South Station, which is the largest transport hub 
in Boston. South Station is on the Red Line of the MBTA subway and is easy to 
get to from any other "T" stop with a maximum of 1 transfer.

If you were incredibly, world-class cheap, you could even stay way out in the 
suburbs and take the commuter rail into South Station for the conference. 
Personally, if I wanted to save money, I'd look out toward Quincy Adams on the 
south end of the Red Line for a cheaper place to stay, and take the Red Line 
into South Station.

Here's a map showing the subway and commuter rail lines:
http://www.mbta.com/schedules_and_maps/rail/

--n
On Mon, Aug 5, 2013 at 8:12 AM, Philip Balister 
mailto:phi...@balister.org>> wrote:
I am looking at hotels in Boston GR Con. Needless to say, I will never
complain about Si valley rates again.

Does anyone have any comments about public transport in Boston?
Especially about getting from cheaper hotels to the conference location.

Thanks,

Philip

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

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

Re: [Discuss-gnuradio] Public transport in Boston

[Ben Reynwar]

There are also a few backpacking hostels in downtown boston, some of
which probably have private rooms.  Not quite the same as a hotel, but
normally way cheaper.

On Mon, Aug 5, 2013 at 8:12 AM, Philip Balister  wrote:
> I am looking at hotels in Boston GR Con. Needless to say, I will never
> complain about Si valley rates again.
>
> Does anyone have any comments about public transport in Boston?
> Especially about getting from cheaper hotels to the conference location.
>
> Thanks,
>
> Philip
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] Dynamic number of "message" ports using nports

[Eric B]

>So I think its sort of fundamental the the message ports cant be scaled
>like that because they are named and not linearly indexed. You could
>find a way do to it, but its a more invasive GRC change I guess. Perhaps
>Martin's GSoC student might consider doing this for the GRC
>improvements, if not already?
>
>-josh

Thanks for confirming my suspicion. My ultimate goal was to bury the
connections inside a hierarchical block anyway so I did that and just
programmatically named and connected the ports which works fine. I just
can't expose the constituent blocks in GRC.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Dynamic-number-of-message-ports-using-nports-tp42766p42969.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] ATSC fixups

[M. Ranganathan]

Hello,

I git cloned the atscfixup branch and tried building it. Here's as far as I
got:

In file included from
/users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27:
/users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44:
error: gnuradio/atsc/diag_output_impl.h: No such file or directory

Perhaps this file was accidentally left out of the repository (?)

Ranga





On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan  wrote:

> On 07/15/2013 07:01 PM, Andrew Davis wrote:
>
> > After this stuff and the reorganization a simple diff would not have
> > saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would
> > be confusing, hence the name change.
>
> First, let me say that I'm very happy this code is getting some
> attention. It was originally written to use the low-IF output of a TV
> tuner and ADC, and also when GNU Radio only had a single-threaded
> scheduler.  Later, it was only minimally modified to use the USRP
> complex baseband IQ output. (I wasn't around GNU Radio at the time and
> the above is only what I surmise by looking at the code history.)
>
> The changes you describe are more like it would have been written had
> the USRP existed at the time.
>
> The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I
> merged in, but he and I never finished what we were going to do with it.
>
> > Also the other scripts seem unnecessary with the new
> > thread-per-block sceduler, the also seem to cause a lot of beginners
> > confusion. So I felt they needed to go.
>
> Agree.
>
> > I have also built a ( semi ) working complex fpll for gr-atsc, this
> > removes the need for up-converting and the filtering after the
> > current fpll, my next atsc_rx will need the new script style. After I
> > finish updating the bit timing loop we will be almost real time I
> > believe!
>
> The upconversion and filtering is a large CPU waste when it could be
> done at baseband, but it seems this was just a quick-and-dirty way to
> get the baseband IQ from a USRP to look like a low-IF output instead in
> order to re-use what was already written and working.
>
> Real-time execution would be a welcome accomplishment!
>
> > P.S. I could still just do the diff to the old all_atsc.py and rename
> > if you want.
>
> No need.
>
> By the way, before any of this can be merged, we'll need a copyright
> assignment from you.  I'll email you off-list about how this works.
>
> Thanks again for working on this.
>
> --
> 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
>
>


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

Re: [Discuss-gnuradio] Build problems on mac os 10.8

[Michael Dickens]

On Aug 3, 2013, at 9:16 AM, Tom Rondeau  wrote:
> Please see the log file for port py27-wxpython-devel for details:
> 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py27-wxpython-devel/py27-wxpython-devel/main.log

Hi Ching - I'm back from a wonderful vacation, completely off the grid for 1 
week.

I know there has been a lot of work recently to get the WX ports better aligned 
with their purposes, so possibly the port in issue (py27-wxpython-devel) is no 
longer the way to go for GNU Radio's WXGUI.  I haven't had time yet to see 
what's going on with the WX ports; I've just read about them in commit logs.

Here's what I recommend doing if this is still an issue

{{{
sudo port clean py27-wxpython-devel
sudo port selfupdate
sudo port install py27-wxpython-devel
}}}

and if that fails, then:

{{{
cp `port logfile py27-wxpython-devel` ~/Desktop/log-py27-wxpython-devel.txt
bzip2 ~/Desktop/log-py27-wxpython-devel.txt
}}}

and then email me, off-list, the resulting compressed logfile.  I'll look it 
over and get back to you and we'll work out a way to get GNU Radio working for 
you, eventually.

If the above works, then try "sudo port install gnuradio +full" again to see 
what comes of it.

Feel free to email me off-list with any issues trying to install the gnuradio 
port within MacPorts, even if the issue is not with GNU Radio itself.  I'll 
help folks out as my time allows, which in the past few months has meant 1-2 
emails per day of advice per issue. - MLD


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

Re: [Discuss-gnuradio] ATSC fixups

[Andrew Davis]

It was removed and left in fpll.h, i'll push a fix in just a bit, in
the meantime you could just remove the include line from fpll.h

Thank you
Andrew


On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan  wrote:

> Hello,
>
> I git cloned the atscfixup branch and tried building it. Here's as far as
> I got:
>
> In file included from
> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27:
> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44:
> error: gnuradio/atsc/diag_output_impl.h: No such file or directory
>
> Perhaps this file was accidentally left out of the repository (?)
>
> Ranga
>
>
>
>
>
> On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan <
> johnat...@corganlabs.com> wrote:
>
>> On 07/15/2013 07:01 PM, Andrew Davis wrote:
>>
>> > After this stuff and the reorganization a simple diff would not have
>> > saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would
>> > be confusing, hence the name change.
>>
>> First, let me say that I'm very happy this code is getting some
>> attention. It was originally written to use the low-IF output of a TV
>> tuner and ADC, and also when GNU Radio only had a single-threaded
>> scheduler.  Later, it was only minimally modified to use the USRP
>> complex baseband IQ output. (I wasn't around GNU Radio at the time and
>> the above is only what I surmise by looking at the code history.)
>>
>> The changes you describe are more like it would have been written had
>> the USRP existed at the time.
>>
>> The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I
>> merged in, but he and I never finished what we were going to do with it.
>>
>> > Also the other scripts seem unnecessary with the new
>> > thread-per-block sceduler, the also seem to cause a lot of beginners
>> > confusion. So I felt they needed to go.
>>
>> Agree.
>>
>> > I have also built a ( semi ) working complex fpll for gr-atsc, this
>> > removes the need for up-converting and the filtering after the
>> > current fpll, my next atsc_rx will need the new script style. After I
>> > finish updating the bit timing loop we will be almost real time I
>> > believe!
>>
>> The upconversion and filtering is a large CPU waste when it could be
>> done at baseband, but it seems this was just a quick-and-dirty way to
>> get the baseband IQ from a USRP to look like a low-IF output instead in
>> order to re-use what was already written and working.
>>
>> Real-time execution would be a welcome accomplishment!
>>
>> > P.S. I could still just do the diff to the old all_atsc.py and rename
>> > if you want.
>>
>> No need.
>>
>> By the way, before any of this can be merged, we'll need a copyright
>> assignment from you.  I'll email you off-list about how this works.
>>
>> Thanks again for working on this.
>>
>> --
>> 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
>>
>>
>
>
> --
> M. Ranganathan
>
> ___
> 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] Help: Constellation Receiver::Object

[Adeel Anwar]

Tom,

>>I am trying to use the Constellation Receiver Block and one of the
Parameters is "Constellation Object". Is this a pointer to an object and
>>how/what creates this object? I have looked at the qam.py file but don't
follow how this relates to placing a block down in gnuradio >>companion.
In GRC u can use
  1) from gnuradio import digital  (Using Import block)
  2) my_const_obj = digital.constellation_qpsk()  (Using variable block).
To see other options for creating the constellation object see

http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1constellation.html
  3) In constellation receiver>constellation Object parameter add
my_const_obj.base()

-Adeel


On Mon, Aug 5, 2013 at 7:17 PM, tom sutherland wrote:

> I am trying to use the Constellation Receiver Block and one of the
> Parameters is "Constellation Object". Is this a pointer to an object and
> how/what creates this object? I have looked at the qam.py file but don't
> follow how this relates to placing a block down in gnuradio companion.
> Thanks...Tom
>
> Sent from Yahoo! Mail on Android
>
> ___
> 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] ATSC fixups

[Andrew Davis]

OK, pushed, could you see if that works better?

Thank you
Andrew


On Mon, Aug 5, 2013 at 2:50 PM, Andrew Davis wrote:

> It was removed and left in fpll.h, i'll push a fix in just a bit, in
> the meantime you could just remove the include line from fpll.h
>
> Thank you
> Andrew
>
>
> On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan  wrote:
>
>> Hello,
>>
>> I git cloned the atscfixup branch and tried building it. Here's as far as
>> I got:
>>
>> In file included from
>> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27:
>> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44:
>> error: gnuradio/atsc/diag_output_impl.h: No such file or directory
>>
>> Perhaps this file was accidentally left out of the repository (?)
>>
>> Ranga
>>
>>
>>
>>
>>
>> On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan <
>> johnat...@corganlabs.com> wrote:
>>
>>> On 07/15/2013 07:01 PM, Andrew Davis wrote:
>>>
>>> > After this stuff and the reorganization a simple diff would not have
>>> > saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would
>>> > be confusing, hence the name change.
>>>
>>> First, let me say that I'm very happy this code is getting some
>>> attention. It was originally written to use the low-IF output of a TV
>>> tuner and ADC, and also when GNU Radio only had a single-threaded
>>> scheduler.  Later, it was only minimally modified to use the USRP
>>> complex baseband IQ output. (I wasn't around GNU Radio at the time and
>>> the above is only what I surmise by looking at the code history.)
>>>
>>> The changes you describe are more like it would have been written had
>>> the USRP existed at the time.
>>>
>>> The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I
>>> merged in, but he and I never finished what we were going to do with it.
>>>
>>> > Also the other scripts seem unnecessary with the new
>>> > thread-per-block sceduler, the also seem to cause a lot of beginners
>>> > confusion. So I felt they needed to go.
>>>
>>> Agree.
>>>
>>> > I have also built a ( semi ) working complex fpll for gr-atsc, this
>>> > removes the need for up-converting and the filtering after the
>>> > current fpll, my next atsc_rx will need the new script style. After I
>>> > finish updating the bit timing loop we will be almost real time I
>>> > believe!
>>>
>>> The upconversion and filtering is a large CPU waste when it could be
>>> done at baseband, but it seems this was just a quick-and-dirty way to
>>> get the baseband IQ from a USRP to look like a low-IF output instead in
>>> order to re-use what was already written and working.
>>>
>>> Real-time execution would be a welcome accomplishment!
>>>
>>> > P.S. I could still just do the diff to the old all_atsc.py and rename
>>> > if you want.
>>>
>>> No need.
>>>
>>> By the way, before any of this can be merged, we'll need a copyright
>>> assignment from you.  I'll email you off-list about how this works.
>>>
>>> Thanks again for working on this.
>>>
>>> --
>>> 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
>>>
>>>
>>
>>
>> --
>> M. Ranganathan
>>
>> ___
>> 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] Fwd: GNU Radio help

[Marcus Müller]

Hi Vaibhav Rayanade,

your rx sees zero bytes, meaning that the packet decoder does not see any valid 
packets.
That basivally means it can't decode anything... this can imply a lot of things 
that happened between
the tx and the rx USRP, including:
- path loss,
- clipping due to high gain,
- frequency offset between LOs of tx and rx USRP,
- wrong antenna for carrier frequency (125 MHz is _kind of_ low... 1/2\lambda 
is 1.2m),
- wrong frequency for daughterboard (only mixing daughterboard supporting 
125MHz rx+tx is wbx to my knowledge, you have one of these?),
- evil multipath, path loss, all kinds of fading, and all the other effects you 
expect on an RF channel.

Greetings
Marcus

On 08/05/2013 08:13 PM, vaibhav rayanade wrote:


1. attached is the GRC file for "FILE TRANSFER USING USRP AND GNU RADIO".

2. the flow graph works fine when done with loop back from modulator to 
demodulator. but it does not work when connected with USRP. both receive and 
trans paths are on different machines.

3.  file received is always zero bytes. i could not find the reason why.

will you please help

thank you...



___
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] Portable battery for USRPs

[Marcus Müller]

At work, we use a 12V motorbike lead battery with a cigarette lighter plug and 
an
off-the-shelf dc/dc converter.
As of late, someone has designed a small case with a switch on top, housing a
cheap downconverter (linear I guess). Works for hours and hours and hours...

On 07/29/2013 07:46 PM, aseem wadhwa wrote:

Hi!

I have to do a few outdoor experiments with USRPs. Hence I'm looking for 
portable batteries that can be used for this purpose. After searching a bit, 
the best option that seems to me is to use 12V heavy duty lantern battery 
followed by a 12V to 110V DC to AC inverter, which can then be used for the 
USRP adapter. The combined assembly is still a bit heavy for me. Is there any 
other better (lighter) option ? Are there any batteries specifically designed 
to be used with USRPs ?

Thanks in advance.

regards,
Aseem

--
Aseem Wadhwa
Graduate Student
Electrical & Computer Engineering
University of California Santa Barbara


___
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] ctest failures only in i586 builds

[Barry Jackson]

Our gnuradio-3.7.1 package (from recent git) builds for x86_64 now pass 
all tests on the Mageia build system. (qa_qtgui is excluded).


I found that we needed to export LD_LIBRARY_PATH=%{buildroot}%{_libdir} 
in the build chroot for ctest to find the libs.


However I am seeing test failures on the i586 build.

The tests are run during the rpm package build with:

ctest -V -E  qa_qtgui ||:

..so the tests are verbose and failures don't stop the build.

Can anyone figure out why these tests fail only in the i586 build?

i586 build log:
http://mtf.no-ip.co.uk/pub/linux/barjac/tests/i586.log

x86_64 build log:
http://mtf.no-ip.co.uk/pub/linux/barjac/tests/x86_64.log

Thanks,

Barry

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

[Discuss-gnuradio] question about overruns with simple flowgraph

[Stephen]

Hi,

I have a simple FM broadcast receiver flowgraph in c++ that causes
overruns. I'm using a B100 with a wbx daughter board. The flowgraph is

usrp source -> lowpass filter -> quad demod -> deemphasis -> audio lp
filter -> constant multiply -> audio sink

The sample rate is 250K. It works but after a couple of seconds the
overruns start. I've used much more complicated flowgraphs than this
with much higher sampling rates with out overruns. Looking at the cpu
utilization shows each core at less than 5%. Would anyone have any
suggestions for what to look at that could be causing the problem?

thanks,
stephen



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

Re: [Discuss-gnuradio] question about overruns with simple flowgraph

[Nick Foster]

On Mon, Aug 5, 2013 at 5:53 PM, Stephen  wrote:

>
> Hi,
>
> I have a simple FM broadcast receiver flowgraph in c++ that causes
> overruns. I'm using a B100 with a wbx daughter board. The flowgraph is
>
> usrp source -> lowpass filter -> quad demod -> deemphasis -> audio lp
> filter -> constant multiply -> audio sink
>
> The sample rate is 250K. It works but after a couple of seconds the
> overruns start. I've used much more complicated flowgraphs than this
> with much higher sampling rates with out overruns. Looking at the cpu
> utilization shows each core at less than 5%. Would anyone have any
> suggestions for what to look at that could be causing the problem?
>

It's been called the "two-clock" problem. Basically, your soundcard's clock
is decoupled from the USRP's clock, and neither is ideal -- they have
error. As they drift apart either the audio clock will run slower
(producing overruns) or faster (producing underruns).

Here's an older discussion of the same issue.
https://www.ruby-forum.com/topic/209464

A couple of seconds seems pretty fast, however. Make sure you're resampling
the audio to a rate which is actually supported by your soundcard.

--n


>
> thanks,
> stephen
>
>
>
> ___
> 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] question about overruns with simple flowgraph

[Marcus D. Leech]

On 08/05/2013 09:00 PM, Nick Foster wrote:



A couple of seconds seems pretty fast, however. Make sure you're 
resampling the audio to a rate which is actually supported by your 
soundcard.


--n

The two-clock problem tends to manifest as the occasional "click" or 
occasional 'O'.


But if the rates between USRP source, and audio sink are significantly 
mis-matched, you end up with overruns very quickly, since buffers will
  start to fill up to exhaustion, since the sink isn't taking samples 
as fast as they're being produced.


There's no "magic" rate-adaptation in Gnu Radio.  If you have a filter 
block that is decimating down to, let's say, 50kHz, and then feed it into
  an audio sink that's expecting data at 48kHz, things will get stuffed 
pretty quickly.  Just because a (hardware) sink is expect data at
  some rate, doesn't mean that Gnu Radio automatically "tweaks" the 
flow graph to deliver data at that rate.  Gnu Radio is a streaming
  architecture, it doesn't actually inherently "know" about sample 
rates, so you have to take care of decimating/interpolating data streams

  so that things "match".


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


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

Re: [Discuss-gnuradio] question about overruns with simple flowgraph

[Marcus D. Leech]

On 08/05/2013 09:48 PM, Stephen wrote:


On 8/5/2013 8:17 PM, Marcus D. Leech wrote:

On 08/05/2013 09:00 PM, Nick Foster wrote:


A couple of seconds seems pretty fast, however. Make sure you're
resampling the audio to a rate which is actually supported by your
soundcard.

--n


The two-clock problem tends to manifest as the occasional "click" or
occasional 'O'.

But if the rates between USRP source, and audio sink are significantly
mis-matched, you end up with overruns very quickly, since buffers will
   start to fill up to exhaustion, since the sink isn't taking samples as
fast as they're being produced.

There's no "magic" rate-adaptation in Gnu Radio.  If you have a filter
block that is decimating down to, let's say, 50kHz, and then feed it into
   an audio sink that's expecting data at 48kHz, things will get stuffed
pretty quickly.  Just because a (hardware) sink is expect data at
   some rate, doesn't mean that Gnu Radio automatically "tweaks" the flow
graph to deliver data at that rate.  Gnu Radio is a streaming
   architecture, it doesn't actually inherently "know" about sample
rates, so you have to take care of decimating/interpolating data streams
   so that things "match".



A, now I see. I am getting frequent 'O' and audio clicks and pops. I
had played with the various rates till I got the final audio decimation
very close to an integer value but not quite. The integer value used was
a little lower than needed. I adjusted things some more and got a set of
rates that resulted in an integer decimation for the audio lp filter and
that fixed the problem.

The link to the previous discussion was interesting.

thanks, guys
stephen



I tend to use the fractional interpolator--you can get exact rate 
matching that way.  It doesn't seem that expensive, particularly when I 
use it at the

  "low speed" part of the graph near the audio subsystem.




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

Re: [Discuss-gnuradio] Build problems on mac os 10.8

[Michael Dickens]

There's a ticket open at  with this 
issue, so it's being tracked and worked on.  I do not yet have a good solution 
except to revert back to the prior version if you still have it installed.  WX 
has been a pain for a long time, and likely will remain so for a while longer.  
I'll post again once I know more or figure out a work-around. - MLD

On Aug 5, 2013, at 2:36 PM, Michael Dickens  wrote:
> I know there has been a lot of work recently to get the WX ports better 
> aligned with their purposes, so possibly the port in issue 
> (py27-wxpython-devel) is no longer the way to go for GNU Radio's WXGUI.  I 
> haven't had time yet to see what's going on with the WX ports; I've just read 
> about them in commit logs.


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

Re: [Discuss-gnuradio] question about overruns with simple flowgraph

[Stephen]

On 8/5/2013 8:17 PM, Marcus D. Leech wrote:
> On 08/05/2013 09:00 PM, Nick Foster wrote:
>>
>>
>> A couple of seconds seems pretty fast, however. Make sure you're
>> resampling the audio to a rate which is actually supported by your
>> soundcard.
>>
>> --n
>>
> The two-clock problem tends to manifest as the occasional "click" or
> occasional 'O'.
> 
> But if the rates between USRP source, and audio sink are significantly
> mis-matched, you end up with overruns very quickly, since buffers will
>   start to fill up to exhaustion, since the sink isn't taking samples as
> fast as they're being produced.
> 
> There's no "magic" rate-adaptation in Gnu Radio.  If you have a filter
> block that is decimating down to, let's say, 50kHz, and then feed it into
>   an audio sink that's expecting data at 48kHz, things will get stuffed
> pretty quickly.  Just because a (hardware) sink is expect data at
>   some rate, doesn't mean that Gnu Radio automatically "tweaks" the flow
> graph to deliver data at that rate.  Gnu Radio is a streaming
>   architecture, it doesn't actually inherently "know" about sample
> rates, so you have to take care of decimating/interpolating data streams
>   so that things "match".
> 
> 

A, now I see. I am getting frequent 'O' and audio clicks and pops. I
had played with the various rates till I got the final audio decimation
very close to an integer value but not quite. The integer value used was
a little lower than needed. I adjusted things some more and got a set of
rates that resulted in an integer decimation for the audio lp filter and
that fixed the problem.

The link to the previous discussion was interesting.

thanks, guys
stephen




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

Re: [Discuss-gnuradio] Problem faced with clock_recovery_mm at low data rates

[Waqas Bin Abbas]

We did not try clock_recovery_mm for that much low samples per symbols.
Minimum samples per symbols that we used was 24.

Waqas 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Problem-faced-with-clock-recovery-mm-at-low-data-rates-tp42591p42985.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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