Re: [Discuss-gnuradio] Question about adding your own classes

[Tom Rondeau]

On Mon, Sep 23, 2013 at 12:24 AM, Tommy Tracy II  wrote:
> Perfect,
>
> Thank you everyone. What I did was include the header files in my block
> source files; I needed to add them to the CMakeLists.txt in /lib under:
> list(APPEND router_sources
> to get everything to build and link correctly.
>
> I was then able to import the module and use it without error in python.
> From now on I will use 'no block'.

Great!

> -
>
> The next question I have is... is there any documentation on creating GNU
> Radio programs in c++ including the build instructions? I want to test my
> code in a c++ program as well. I saw the example dial_tone, but I'm not sure
> what else I need to include to build it. dial_tone also doesn't seem to work
> in my virtual machine with the following error:
>
> tjt7a@ubuntu:~/Src/pybombs/src/gnuradio$
> ./build/gr-audio/examples/c++/dial_tone
> audio_oss_sink: /dev/dsp: No such file or directory
> terminate called after throwing an instance of 'std::runtime_error'
>   what():  audio_oss_sink
> Aborted (core dumped)

We've always just pointed to the dial tone example for how to build
C++-only projects. I don't think that we've produced a tutorial on how
to do it, though someone else may have.

As for your problem, what you are seeing is just an audio driver
issue. In your VM, does your sound work at all? Do you know what
device or audio system you are using (OSS, ALSA, Pulseaudio, etc)? The
/dev/dsp is assuming OSS. The dial_tone.cc file is pretty light on
features. You'll have to get in there and edit it to change the device
it's using. Go to the "audio::sink::make(rate)" and change that to
"audio::sink::make(rate, device)" where 'device' is the device name
that you want to use. If you are using Ubunut, say, in your VM and
sound works fine with it, you can likely use "pulse" as your device
name. Recompile and try that.

Tom



> Sincerely,
> Tommy James Tracy II
> Ph.D Student
> High Performance Low Power Lab
> University of Virginia
> Phone: 913-775-2241
>
> On Sep 21, 2013, at 11:21 AM, Tom Rondeau  wrote:
>
> On Fri, Sep 20, 2013 at 7:13 PM, Martin Braun (CEL)
>  wrote:
>
> Hi Tommy,
>
> is this a visibility issue? Did you use modtool to add the additional
> classes? If not, do you have a FOO_API macro in your class def?
>
> MB
>
>
> Tommy,
>
> Yes, make sure that the FOO_API is declared for the classes. Also, you
> have to make sure they are being imported into the swig module
> correctly in gr-foo/swig/foo_swig.i.
>
> You can use gr_modtool with the class type "noblock" to create classes
> that are not gr::blocks for this purpose, which will set up the cmake
> and swig files correctly.
>
>
> On Fri, Sep 20, 2013 at 01:58:16PM -0400, Tommy Tracy II wrote:
>
> Dear List,
>
>
> I am using gr_modtool to create new modules and blocks, and I have a
> question
> about adding additional .cc/.h files that are not included by gr_modtool to
> the
> cmake file or otherwise importing them by hand.
>
>
> My new blocks are dependent on two new classes called
> NetworkInterface.{cc,h}
> and EthernetConnector.{cc,h}. During the make process, if there is a syntax
> error in either of these files, the compiler will alert me. I was able to
> fix
> all problems and get the cmake, make, and make install completed. The
> problem
> manifested itself when I attempted to import the module:
>
> --
>
> import router
>
>
> Traceback (most recent call last):
>
>  File "", line 1, in 
>
>  File
> "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/__init__.py",
> line 45, in 
>
>from router_swig import *
>
>  File "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/
> router_swig.py", line 26, in 
>
>_router_swig = swig_import_helper()
>
>  File "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/
> router_swig.py", line 22, in swig_import_helper
>
>_mod = imp.load_module('_router_swig', fp, pathname, description)
>
> ImportError: /home/tjt7a/Src/target/lib/libgnuradio-router.so: undefined
> symbol: _ZN16NetworkInterface7connectEPc
>
> --
>
> To investigate the definition of this symbol, I ran c++filt
>
> --
>
> $c++filt _ZN16NetworkInterface7connectEPc
>
> NetworkInterface::connect(char*)
>
> --
>
> This indicates, that my libgnuradio-router module cannot access the
> NetworkInterface object file, even though it was part of the compilation
> step.
>
>
> My thought process was to create the two shared object (.so) files by hand,
> and
> move them to my python path location. So I did that:
>
> --
>
> cc -shared -o libEthernetConnector.so -fPIC EthernetConnector.cc
>
> cc -shared -o libNetworkInterface.so -fPIC NetworkInterface.cc
>
> I then copied them to the location of my gnuradio .so files
>
> --
>
>
> Unfortunately, this still hasn't solved the problem. Does anyone know a
> solution to this problem?
>
>
> Tommy James Tracy II
>
> Ph.D Student
>
> High Performance Low Power Lab
>
> University of Virginia
>
> Phone: 913-775-22

Re: [Discuss-gnuradio] Constellations in OOT projects

[Michael Berman]

Tom,

Thanks for the response.  This is what i was thinking was the appropriate
action, I just wanted to make sure.  As for the header, I didn't realize I
didn't add one until after I sent the email out; I'll try to not let that
one happen again.


Thanks,

Michael Berman


On Sat, Sep 21, 2013 at 8:09 AM, Tom Rondeau  wrote:

> On Fri, Sep 20, 2013 at 7:55 PM, Michael Berman 
> wrote:
> > I am attempting to add a custom constellation class to be used with the
> > generic_mod_demod object for digital PSK.  I have the code working as a
> > simple addition to the gnuradio source with a re-compilation, however I
> > would like to set this up similar to an Out Of Tree module (although it
> > isn't entirely a standalone module).  Would the way I go about
> approaching
> > this be the same as the adding an Out Of Tree module tutorial on the
> > gnuradio website?  Or would there be a preferred method than the
> gr_modtool.
> > I would like to set this up so that the code I add sits in the
> gr::digital
> > scope and have everything look as though it all sits in the
> > constellation.{cc, h, i} files.  Does anybody have recommendations for
> > attacking this task?
> >
> >
> > Thank you very much,
> >
> > Michael Berman
>
> Hi Michael,
> Please use a proper subject line in the future to help us sort and
> keep track of things.
>
> As to your question, that shouldn't be a problem. You should be able
> to create a class in your OOT module and inherit from
> gr::digital::constellation (or one of it's children). And just putting
> it inside the gr::digital namespace. This will obviously now exist in
> your own lib.so and not in libgnuradio-digital.so. So I'm
> not sure what you mean by "sits inside constellation.{cc,h,i}". If you
> are in an OOT project, you wouldn't be able to add this directly to
> the gnuradio-digital library or Python module (ok, there's a way to do
> the latter by smashing it in during install, but that's seriously ugly
> business that you want no part of).
>
> And use gr_modtool. Definitely the best, easiest, and preferred way of
> setting things up. When creating your new class, use 'gr_modtool add'
> and for the 'code type' use 'noblock.'
>
> --
> Tom
> GRCon13 Oct. 1 - 4
> http://www.trondeau.com/grcon13
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[Marcus D. Leech]

I did a similar experiment with R820T based dongles using an external high 
quality reference and a common signal source. 

The results were poor with a lot of mutual phase noise between two dongles. 

What sample rates did you try and was this E4000 or R820T tuners?

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


On Sep 23, 2013, at 7:59 AM, Juha Vierinen  wrote:

> I was playing around with the rtl_sdr dongles and came up with a trivial hack 
> to build a receiver with multiple coherent channels. I do this basically by 
> unsoldering the quartz clock on the slave units and cable the clock from the 
> master rtl dongle to the slave units (I've attached some pictures). 
> 
> You still have to do sample alignment in software, but this is relatively 
> easy. There are a lot of cool applications, such as a dual frequency beacon 
> satellite receiver, interferometry, or passive radar that you can now do with 
> $16. 
> 
> juha
> 
> 
> ___
> 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

[Discuss-gnuradio] Still missing gnuradio-runtime in OOT modules...

[Achilleas Anastasopoulos]

I have the latest master installed and tested on a 64bit Fedora 18 .
When I generate an OOT module with gr_modtool i still cannot build/compile,
since I get the error

-- checking for module 'gnuradio-runtime'
--   package 'gnuradio-runtime' not found
-- Could NOT find GNURADIO_RUNTIME (missing:  GNURADIO_RUNTIME_LIBRARIES)

when I cmake it.

I followed the instructions for copying the FindGnuradioRuntime.cmake file
as suggested in a previous post but it still does not work for me...

Any suggestions?

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

[Discuss-gnuradio] tb.start(), tb.wait() or tb.stop() dows not work ... help

[shakib034]

I am new to GNURADIO environment.

I want the flow graph that i am working with to turn ON and OFF with 5 sec
of interval. 

I tried  tb.start(), tb.wait(), tb.stop() and sleep(5). 

But that is not working. 

whenever I try to replace "tb.Run(True)" with any thing the program does not
work. 

Any suggestion will be greatly appreciated. 

Thanks.



#
if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = RX_ED_FILE()
tb.Run(True)

#




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/tb-start-tb-wait-or-tb-stop-dows-not-work-help-tp43791.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] AGC and Dynamic Range of ADC

[bob wole]

Can somebody please guide me on this ?

Bob


On Fri, Sep 20, 2013 at 4:44 PM, bob wole  wrote:

> I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210
> motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC
> ? if yes, which one? If not, then won't the varying input signal (for
> example signal from moving object)  to ADC affect the performance of ADC ?
>
> Bob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AGC and Dynamic Range of ADC

[Marcus D. Leech]

On 09/23/2013 11:07 PM, bob wole wrote:

Can somebody please guide me on this ?

Bob


On Fri, Sep 20, 2013 at 4:44 PM, bob wole > wrote:


I have USRPN210 with WBX and RFX2400. Is there any AGC chip on
N210 motherboard or WBX, RFX2400 before ADC to utilize the dynamic
range of ADC ? if yes, which one? If not, then won't the varying
input signal (for example signal from moving object)  to ADC
affect the performance of ADC ?

Bob


The ADC on an N210 has over 80dB of dynamic range.  If that isn't 
enough, then your application can adjust the RF gain to taste.


Only a subset of applications actually benefit from the usual hardware 
AGC schemes, and such schemes are invariably application-specific, so 
there's
  no *automatic* gain control.  But your application can dynamically 
make gain adjustments as it goes.





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