Re: [Discuss-gnuradio] [Openbts-discuss] -------'Range' network is not detected-------

[Ralph A. Schmid, dk5ras]

First of all, it is normal that the USRP is not detected anymore with the uhd 
tools when it is claimed by OpenBTS. So this looks not alarming.

 

Are you able to verify if RF is transmitted? Is there some spectrum analyzer 
available, or a receiver that can tune into the used GSM frequency, best is AM 
mode and open squelch, to see if a carrier is present? This way you can find 
out if it transmits at all, and if so, it must be continously, uninterruptes, 
without stuttering.

 

I assume your successful tests used the very same USRP, so the frequency should 
not be off too far?!

 

Ralph.

 

From: Zamrath Nizam [mailto:zamiguy...@gmail.com] 
Sent: Tuesday, March 24, 2015 5:33 AM
To: openbts-disc...@lists.sourceforge.net; GNURadio Discussion List
Subject: [Openbts-discuss] ---'Range' network is not detected---

 

Hi all,

 

I have recently installed OpenBTS-2.8 on a Banana-Pi (Processor: ARMv7) board 
for USRP N210 functioning. All the prerequisites including GNURadio, UHD were 
successfully built on the board prior to OpenBTS installation. With all 
configurations done, still there is a problem in the USRP connection.

I have configured MCC, MNC and ethernet IP connection. "ping 192.168.10.2" 
works fine. Once the ethernet connection is established and until "./OpenBTS" 
is executed, "uhd_find_devices" and "uhd_usrp_probe" detect USRP. After the 
execution of "./OpenBTS", surprisingly "uhd_find_devices" and "uhd_usrp_probe" 
do not detect the device and say "No device found..." ('ping' is still working 
though). The strangest thing is even at this stage, "./OpenBTS" works fine even 
at a re-run. 

After all these drama, no ('range') network is detected by a properly 
configured mobile phone. (Note: We have successfully placed calls and SMS with 
almost same procedure using a PC instead of B-Pi). 

I am bit confused here whether this is a deal of OpenBTS or GNURadio. Does the 
processor speed come in to play in this scenario?

Any valuable suggestions would be highly appreciated.

 

Thank you.

 

Zamrath Nizam

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

Re: [Discuss-gnuradio] [USRP-users] Spikes in b210 received data

[Arjun Nadh]

Hi Tom,
I have tried reducing the signal level. The signal level at the input is
now -40dBm. Still there is this ramp behaviour.

I also get this  when I use the B210 in loopback mode (with a 30dB
atttenuator in the loop). Also I have observed that
the lower the master clock rate that I set, the less frequent the ramps.

Thank you,

Arjun Nadh



On Tue, Mar 24, 2015 at 5:56 AM, Tom Tsou  wrote:

> Hi Arjun,
>
> On Fri, Mar 20, 2015 at 11:15 PM, Arjun Nadh via USRP-users
>  wrote:
> > On observing the received samples, there is a periodic " ramp " on the
> > received sample. Attaching the plot. I do not observe this effect while
> > using N210. Also I do not observe this if I use the internal clock.
>
> Can you reduce the level on the VSG by a few dB and see if that
> changes the behavior?
>
> And is the ramp effect consistently tied to the use of the external
> reference? or is the relationship intermittent?
>
>   -TT
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] -------'Range' network is not detected-------

[Zamrath Nizam]

Hi all,

I have recently installed OpenBTS-2.8 on a Banana-Pi (Processor: ARMv7)
board for USRP N210 functioning. All the prerequisites including GNURadio,
UHD were successfully built on the board prior to OpenBTS installation.
With all configurations done, still there is a problem in the USRP
connection.
I have configured MCC, MNC and ethernet IP connection. "ping 192.168.10.2"
works fine. Once the ethernet connection is established and until
"./OpenBTS" is executed, "uhd_find_devices" and "uhd_usrp_probe" detect
USRP. After the execution of "./OpenBTS", surprisingly "uhd_find_devices"
and "uhd_usrp_probe" do not detect the device and say "No device found..."
('ping' is still working though). The strangest thing is even at this
stage, "./OpenBTS" works fine even at a re-run.
After all these drama, no ('range') network is detected by a properly
configured mobile phone. (Note: We have successfully placed calls and SMS
with almost same procedure using a PC instead of B-Pi).
I am bit confused here whether this is a deal of OpenBTS or GNURadio. Does
the processor speed come in to play in this scenario?
Any valuable suggestions would be highly appreciated.

Thank you.

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

Re: [Discuss-gnuradio] pybombs, gnuradio, libprotobuf issues PLEASE HELP ME

[ben Gee]

Ron, thanks, adding that line fixed the compilation error and gnuradio says
that it installed ok!
Now onto the other issues:
NEW ISSUE - no GRC??. I can't call it from the target, home or pybombs
directory and there's no recipe for it. any thoughts?
OLD ISSUE - protobuf is still the old version and calling ./pybombs update
protobuf does nothing
OLD ISSUE - still have no idea where to find a build log for gnuradio


On Mon, Mar 23, 2015 at 6:42 PM, Ron Economos  wrote:

> The first error can be repaired by adding the line:
>
> #include 
>
> to gnuradio/gr-dtv/lib/atsc/atsc_interleaver_impl.cc
>
> I'm not sure how this bug slipped by.
>
> Ron
>
>
> On 03/23/2015 03:01 PM, ben Gee wrote:
>
>> I've picked up some issues over the last month of trying to get a working
>> gnuradio pybombs install with the openlte and fosphor pybombs packages. Had
>> no idea it would be this difficult on a brand new system with a fresh OS
>> install and following all the instructions on the gnuradio site, but i
>> guess that's open source for ya. I'm learning a lot though and hope that my
>> questions will help someone else down the road.
>>
>>
>> 1) can anybody tell me where the install log for pybombs is? I've been
>> told that it exists, but can't find it anywhere.
>>
>> 2)i've been working with Sylvain on getting Fosphor running in my pybombs
>> build, which was having a lot of problems, so just to be on the safe side I
>> decided to try a clean build of gnuradio and pybombs altogether. To do so i
>> did the following:
>> -deleted my pybombs directory
>> -followed the instructions here (https://gnuradio.org/redmine/
>> projects/pybombs/wiki/QuickStart)
>>
>> -ran ./pybombs install gnuradio -v
>>
>> uhd seems to be ok, but gnuradio installation failed with this error:
>>
>> http://pastebin.com/XB9KW9Yx
>>
>> 3) wanting to investigate i ran ./pybombs list i got this error
>>
>> "have_deb: Does not satisfy requirement...installed version of
>> libprotobuf-dev (2.5.0) is not >= than 2.6.1"
>>
>> (./pybombs list output here)
>>
>>
>> so in order to fix the protobuf problem i ran ./pybombs install protobuf
>>
>> which then returns this:
>>
>> http://pastebin.com/rGqwsdYR
>>
>> i'm not sure if the libprotobuf and gnuradio issues are related, but
>> obviously i'm doing something wrong.
>>
>> thanks,
>> -b
>>
>>
>
> ___
> 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] File Sink Unbuffered

[Richard Bell]

Thanks. I'm having trouble recreating the error so I think I want to take
this back. I don't see a difference anymore between buffered and
unbuffered. I had multiple instances of gr open and running when I noticed
the difference. Call it a fluke.

Rich

On Mon, Mar 23, 2015 at 5:50 PM, Marcus D. Leech  wrote:

>  On 03/23/2015 08:27 PM, Richard Bell wrote:
>
>I noticed a large difference in errors between input and output files
> when I turn unbuffered on and off.
>
>  With unbuffered on, there was no difference between my input and output
> file.
>
>  With unbuffered off, there were a lot of small errors that were
> introduced to the output file.
>
>  Is this a known issue, and should I always keep unbuffered on? gr3.7.6
> ubuntu 14.04
>
>  v/r,
>  Rich
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  If you unceremoniously terminate your flow-graph, there will be data in
> 'stdio' buffers that have not yet been  committed to the operating system.
>
> It may be the case, given Gnu Radio's internal buffering mechanism, that
> using "unbuffered" all the time is the right thing to do, unless stdio
>   buffers offer a performance advantage for an application (Gnu Radio, in
> this case) that already does alot of its own buffering.
>
>
>
> ___
> 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] File Sink Unbuffered

[Marcus D. Leech]

On 03/23/2015 08:27 PM, Richard Bell wrote:
I noticed a large difference in errors between input and output files 
when I turn unbuffered on and off.


With unbuffered on, there was no difference between my input and 
output file.


With unbuffered off, there were a lot of small errors that were 
introduced to the output file.


Is this a known issue, and should I always keep unbuffered on? gr3.7.6 
ubuntu 14.04


v/r,
Rich


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
If you unceremoniously terminate your flow-graph, there will be data in 
'stdio' buffers that have not yet been  committed to the operating system.


It may be the case, given Gnu Radio's internal buffering mechanism, that 
using "unbuffered" all the time is the right thing to do, unless stdio
  buffers offer a performance advantage for an application (Gnu Radio, 
in this case) that already does alot of its own buffering.



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

[Discuss-gnuradio] File Sink Unbuffered

[Richard Bell]

I noticed a large difference in errors between input and output files when
I turn unbuffered on and off.

With unbuffered on, there was no difference between my input and output
file.

With unbuffered off, there were a lot of small errors that were introduced
to the output file.

Is this a known issue, and should I always keep unbuffered on? gr3.7.6
ubuntu 14.04

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

Re: [Discuss-gnuradio] [USRP-users] Spikes in b210 received data

[Tom Tsou]

Hi Arjun,

On Fri, Mar 20, 2015 at 11:15 PM, Arjun Nadh via USRP-users
 wrote:
> On observing the received samples, there is a periodic " ramp " on the
> received sample. Attaching the plot. I do not observe this effect while
> using N210. Also I do not observe this if I use the internal clock.

Can you reduce the level on the VSG by a few dB and see if that
changes the behavior?

And is the ramp effect consistently tied to the use of the external
reference? or is the relationship intermittent?

  -TT

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

Re: [Discuss-gnuradio] pybombs, gnuradio, libprotobuf issues PLEASE HELP ME

[Ron Economos]

The first error can be repaired by adding the line:

#include 

to gnuradio/gr-dtv/lib/atsc/atsc_interleaver_impl.cc

I'm not sure how this bug slipped by.

Ron

On 03/23/2015 03:01 PM, ben Gee wrote:
I've picked up some issues over the last month of trying to get a 
working gnuradio pybombs install with the openlte and fosphor pybombs 
packages. Had no idea it would be this difficult on a brand new system 
with a fresh OS install and following all the instructions on the 
gnuradio site, but i guess that's open source for ya. I'm learning a 
lot though and hope that my questions will help someone else down the 
road.



1) can anybody tell me where the install log for pybombs is? I've been 
told that it exists, but can't find it anywhere.


2)i've been working with Sylvain on getting Fosphor running in my 
pybombs build, which was having a lot of problems, so just to be on 
the safe side I decided to try a clean build of gnuradio and pybombs 
altogether. To do so i did the following:

-deleted my pybombs directory
-followed the instructions here 
(https://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart)


-ran ./pybombs install gnuradio -v

uhd seems to be ok, but gnuradio installation failed with this error:

http://pastebin.com/XB9KW9Yx

3) wanting to investigate i ran ./pybombs list i got this error

"have_deb: Does not satisfy requirement...installed version of 
libprotobuf-dev (2.5.0) is not >= than 2.6.1"


(./pybombs list output here)


so in order to fix the protobuf problem i ran ./pybombs install protobuf

which then returns this:

http://pastebin.com/rGqwsdYR

i'm not sure if the libprotobuf and gnuradio issues are related, but 
obviously i'm doing something wrong.


thanks,
-b




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

Re: [Discuss-gnuradio] gr-fosphor with pybombs

[ben Gee]

I appreciate the response. Before you wrote back I wanted to try a fresh
install because i wanted to confirm 100% that there were no conflicting
packages outside my pybombs environment. After i deleted my main pybombs
directory i tried to reinstall pybombs, uhd and gnuradio, but now gnuradio
won't even install, so i'm going to have to hold off on fosphor until i can
get that issue fixed.

i've reached out to the discussion board in a new thread for help with
those issues.

thanks for your help so far

On Thu, Mar 19, 2015 at 6:40 PM, Sylvain Munaut <246...@gmail.com> wrote:

> Also :
>
> > Next, because i have an intel integrated graphics controller in my
> laptop i
> > chose the "Intel CPU OpenCL" option from the instructions
> > i went to the link on the page, but it says that there is no standalone
> > OpenCL SDK package anymore and that you have to download the "Intel Code
> > Builder for OpenCL" so i downloaded and installed this:
> >
> >
> https://software.intel.com/en-us/articles/intel-code-builder-for-opencl-api
>
> Actually if you read everything they say it's still available for linux :
>
> https://software.intel.com/en-us/articles/opencl-drivers#ubuntu64
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs, gnuradio, libprotobuf issues PLEASE HELP ME

[ben Gee]

I've picked up some issues over the last month of trying to get a working
gnuradio pybombs install with the openlte and fosphor pybombs packages. Had
no idea it would be this difficult on a brand new system with a fresh OS
install and following all the instructions on the gnuradio site, but i
guess that's open source for ya. I'm learning a lot though and hope that my
questions will help someone else down the road.


1) can anybody tell me where the install log for pybombs is? I've been told
that it exists, but can't find it anywhere.

2)i've been working with Sylvain on getting Fosphor running in my pybombs
build, which was having a lot of problems, so just to be on the safe side I
decided to try a clean build of gnuradio and pybombs altogether. To do so i
did the following:
-deleted my pybombs directory
-followed the instructions here (
https://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart)

-ran ./pybombs install gnuradio -v

uhd seems to be ok, but gnuradio installation failed with this error:

http://pastebin.com/XB9KW9Yx

3) wanting to investigate i ran ./pybombs list i got this error

"have_deb: Does not satisfy requirement...installed version of
libprotobuf-dev (2.5.0) is not >= than 2.6.1"

(./pybombs list output here)


so in order to fix the protobuf problem i ran ./pybombs install protobuf

which then returns this:

http://pastebin.com/rGqwsdYR

i'm not sure if the libprotobuf and gnuradio issues are related, but
obviously i'm doing something wrong.

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

Re: [Discuss-gnuradio] passing USRP source block shared pointer through SWIG

[Martin Braun]

You should easily be able to pass a basic_block sptr and then 
dynamic-cast it in your block.


What you're trying to do is not recommended procedure, although I can 
see how it's necessary at times. Can you tell us what you're trying to 
do? We've been working on making the message ports more useful, which 
should hopefully take care of most issues.


M

On 23.03.2015 10:13, Anderson, Douglas J. wrote:

Hi all,

I'm looking into the possibility of passing the  object from Python into a C++ out of tree module. In my
module, I have:

 controller_cc_impl::controller_cc_impl(gr::uhd::usrp_source::sptr
usrp, [...])

I get a TypeError when I instantiate the block. It seems like the object
created in Python is not a proxy for the sptr, and I can't figure out
quite how to get access to the sptr from Python.

I've tried both of the alternatives to passing back in the sptr: I've
tried sending commands to the USRP via message passing interface, but
only freq and gain are implemented. At the very least I need the full
tune_request capability.

I've also tried making that call with fevall_dd, but it's a blocking
call and it's too slow for my application. I could maybe spawn that call
in its own thread so it doesn't block, but I think passing the shared
pointer back is the cleaner and more correct solution.

So, how hard is this going to be? SWIG 2.0 supports boost's shared
pointer. I'm wondering if it'd just be a few extra lines in
GR_SWIG_BLOCK_MAGIC2to expose it, or am I kidding myself?

http://www.swig.org/Doc2.0/Library.html#Library_std_shared_ptr

Thanks in advance,
-Doug


___
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] Feature Request

[Martin Braun]

Rich,

GRC has the worst ratio of people committing code (Seth is one of them) 
to importance of the project. There is even an entire wiki page with a 
GRC wishlist: http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCroadmap


...and Sebastian (our main GRC guy) tracks even more stuff on the issue 
tracker. There will be a GRC Working Group call soon. If you (or anyone 
else) would like to contribute, you are very welcome.


Otherwise, GRC feature requests will fall under the bus (besides, it's 
hard to come up with *new* requests -- most people want the same stuff, 
but no one wants to write it).


If you're interested, tell us about it, and keep your eyes open for the 
next WG call.


M

On 23.03.2015 10:28, Seth Hitefield wrote:

Rich,

I have been working on a patch for the second feature you mentioned. It
is the 'ignore_blocks' branch on my github:

https://github.com/sdh11/gnuradio-wg-grc/tree/ignore_blocks

If you run GRC from that branch, pressing 'p' should treat the block as
a pass through block, and it will not show up in a generated python
flow-graph. There are some bugs with it at the moment, but I think that
it is what you are looking for.

- Seth


On 03/23/2015 12:43 PM, Richard Bell wrote:

Hi all,

I wanted to pass a long two features that I wished existed.

I think it would be nice if every block in GRC came with a comment
field. A field for text that does nothing but allow users to add notes
to help others understand they're thinking when they set-up the
parameters of the block. It could be thought of as a user definable
documentation section.

The second was a 'comment through' option. This comments out the block
and passes data through it to the next block. Saves having to mess
with wires between blocks that are commented out.

v/r,
Rich




___
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 on Android

[Tom Rondeau]

On Sun, Mar 22, 2015 at 6:29 PM, Vijay Galbaransingh  wrote:

> Hi guys,
>
> Still stuck, but some relevant details have changed that may help answer my
> question. So I'm trying to implement a sink block for gnuradio-android that
> takes integers on its input (not chars as I had erroneously written before)
> and stores the last 'length' items in a LIFO buffer; the buffer's contents
> are written to an Android TextView object every time the block's work
> function is called. Following is the constructor I have written in order to
> pass this block the JNIEnv and jobject variables it needs in order to
> access
> the methods of my TextView instance:
>
> stream_to_tv_sink_impl::stream_to_tv_sink_impl(JNIEnv *env, jobject
> jtv,
> int length)
>   : gr::sync_block("stream_to_tv_sink",
>   gr::io_signature::make(1, 1, sizeof(int),
>   gr::io_signature::make(0, 0, 0)),
> d_env(env),
> d_jtv(jtv),
> d_length(length)
> {
>   d_buffer = new string[length];
>   for(int i = 0; i < length; i++) {
> d_buffer[i] = "0";
>   }
>   d_output = "Nothing yet...";
>   jclass d_cls = env->GetObjectClass(jtv);
>   jmethodID d_mid = env->GetMethodID(d_cls, "setText",
> "(Ljava/lang/CharSequence;)V");
> }
>
> And here is my work function:
>
> int
> stream_to_tv_sink_impl::work(int noutput_items,
>   gr_vector_const_void_star &input_items,
>   gr_vector_void_star &output_items)
> {
> const int *in = (const int *) input_items[0];
>
> // Update LIFO
> for(int i = d_length - 1; i > 0; i--) {
> d_buffer[i] = d_buffer[i-1];
> }
> d_buffer[0] = to_string(in[0]);
>
> // Construct output string, newest >> oldest (left to right)
> d_output = d_buffer[0];
> for(int i = 1; i < d_length; i++) {
> d_output += " " + d_buffer[i];
> }
>
> // Display output string -- Invoke setText method
> d_env->CallVoidMethod(d_jtv, d_mid,
> d_env->NewStringUTF(d_output.c_str())); // Might need to do this j times
> for
> j < noutput_items
>
> // Tell runtime system how many output items we produced.
> return noutput_items;
> }
>
> Where I am stuck is I cannot figure out how to come up with the appropriate
> makefile (using cmake or otherwise) to build this block into a prebuilt
> static library so that I may use it in my Android flowgraph, as shown for
> example in the instructions for building GNU Radio for Android and GRAnd at
> https://gnuradio.org/redmine/projects/gnuradio/wiki/GRAndBuild. I don't
> have
> much experience tinkering with cmake but I've been looking over the cmake
> files in GRAnd and the android fork of gnuradio and I can't figure out how
> to properly link to the JNI library to build this thing -- or if statically
> linking to JNI types and methods in this manner is even possible. If it
> isn't, I'm open to suggestions for alternative methods of displaying the
> flowgraph's end results in my Android app; at the moment my flowgraph
> terminates in a file sink, and the app reads/displays a few entries from
> the
> file, but this not a good solution for when the flowgraph is running for
> more than 10 or 15 seconds.
>
> Any advice appreciated,
> Vijay


Hi Vijay,

So at this point I think you might be the person with the second most
experience with GNU Radio on Android and therefore the second most
qualified to answer the question :)

I'm sitting in Android sessions at ELC right now, though, so I can't go
into details really here. All I'll say is to look closer at gr-grand.
Specifically, look at the float_array block that I wrote. It uses
jfloatArray and JNIEnv in creating this block, very much like how you want
to handle your block. I might suggest adding your block (using gr_modtool
add in your checkout of gr-grand) directly to gr-grand and try and build it
there, since that CMake handles the necessary includes/libs/etc that you
need to get the linking to work. That might at least get you to a buildable
block for your purposes. It might then help you understand what you need to
do with your own OOT projects CMake files.

Tom




> -Original Message-
> From: discuss-gnuradio-bounces+vijayg=sfu...@gnu.org
> [mailto:discuss-gnuradio-bounces+vijayg=sfu...@gnu.org] On Behalf Of Vijay
> Galbaransingh
> Sent: March-21-15 00:51
> To: 'Tom Rondeau'
> Cc: 'GNURadio Discussion List'
> Subject: Re: [Discuss-gnuradio] GNU Radio on Android
>
> Hi guys,
>
> I am attempting to write an OOT module to be implemented on Android and am
> finding myself out of my depth here.
>
> As a first step I was able to make and execute my flowgraph on my android
> device following the instructions on the wiki, using a file sink to store
> my
> end result (demodulated string.)
>
> Now I would like to create my own sink which takes char inputs and updates
> a
> TextView object as they are ‘

Re: [Discuss-gnuradio] Feature Request

[Seth Hitefield]

Rich,

I have been working on a patch for the second feature you mentioned. It 
is the 'ignore_blocks' branch on my github:


https://github.com/sdh11/gnuradio-wg-grc/tree/ignore_blocks

If you run GRC from that branch, pressing 'p' should treat the block as 
a pass through block, and it will not show up in a generated python 
flow-graph. There are some bugs with it at the moment, but I think that 
it is what you are looking for.


- Seth


On 03/23/2015 12:43 PM, Richard Bell wrote:

Hi all,

I wanted to pass a long two features that I wished existed.

I think it would be nice if every block in GRC came with a comment 
field. A field for text that does nothing but allow users to add notes 
to help others understand they're thinking when they set-up the 
parameters of the block. It could be thought of as a user definable 
documentation section.


The second was a 'comment through' option. This comments out the block 
and passes data through it to the next block. Saves having to mess 
with wires between blocks that are commented out.


v/r,
Rich




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




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] passing USRP source block shared pointer through SWIG

[Anderson, Douglas J.]

Hi all,

I'm looking into the possibility of passing the  object from Python into a C++ out of tree module. In my module, I have:

controller_cc_impl::controller_cc_impl(gr::uhd::usrp_source::sptr usrp, 
[...])

I get a TypeError when I instantiate the block. It seems like the object 
created in Python is not a proxy for the sptr, and I can't figure out quite how 
to get access to the sptr from Python.

I've tried both of the alternatives to passing back in the sptr: I've tried 
sending commands to the USRP via message passing interface, but only freq and 
gain are implemented. At the very least I need the full tune_request capability.

I've also tried making that call with fevall_dd, but it's a blocking call and 
it's too slow for my application. I could maybe spawn that call in its own 
thread so it doesn't block, but I think passing the shared pointer back is the 
cleaner and more correct solution.

So, how hard is this going to be? SWIG 2.0 supports boost's shared pointer. I'm 
wondering if it'd just be a few extra lines in GR_SWIG_BLOCK_MAGIC2 to expose 
it, or am I kidding myself?

http://www.swig.org/Doc2.0/Library.html#Library_std_shared_ptr

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

[Discuss-gnuradio] Feature Request

[Richard Bell]

Hi all,

I wanted to pass a long two features that I wished existed.

I think it would be nice if every block in GRC came with a comment field. A
field for text that does nothing but allow users to add notes to help
others understand they're thinking when they set-up the parameters of the
block. It could be thought of as a user definable documentation section.

The second was a 'comment through' option. This comments out the block and
passes data through it to the next block. Saves having to mess with wires
between blocks that are commented out.

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

[Discuss-gnuradio] FOSDEM Presentations

[Martin Braun]

All of the FOSDEM SDR talks are now online, I've updated the 
presentations page:


http://gnuradio.org/redmine/projects/gnuradio/wiki/Presentations

M

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

Re: [Discuss-gnuradio] Click-to-tune in Qt GUI Frequency SInk

[mleech]

 

Yup, I actually deduced that using a Message Debug block to figure out
what it emits. 

But not a lot of blocks currently accept async messages for handling
run-time parameters. For example, gr-osmosdr only supports
"conventional" setters. 

On 2015-03-23 10:28, Tom Rondeau wrote: 

> On Mon, Mar 23, 2015 at 7:12 AM,  wrote:
> 
>> Indeed, if one uses relative, rather than absolute frequencies in the Qt 
>> Frequency sink, everything is wonderful. 
>> 
>> But I think there are, as you observe, deeper questions about the desired 
>> semantics of async messages of this type. 
>> 
>> An advantage to the "sets a variable" implementation on the WX GUI side, is 
>> that said variable can be manipulated and scaled as appropriate, depending 
>> on who is consuming it. 
>> 
>> It's early days for the async-message subsystem within GR, and we are 
>> learning as we're going. No surprises
> 
> I also just want to point out that the format of the messages is described in 
> the manual 
> 
> http://gnuradio.org/doc/doxygen/classgr_1_1qtgui_1_1freq__sink__c.html [2] 
> 
> See the Detailed Description section. 
> 
> Tom 
> 
> On 2015-03-23 02:12, Martin Braun wrote: 
> 
> On 22.03.2015 19:26, Marcus D. Leech wrote:
> Just looking at the async message interface for Qt GUI Frequency Sink. The 
> "freq" output (is that a PMT?) is always, it appears, in terms of "display" 
> frequency. Which is cool if you're using the click-to-tune output to modify 
> (for example) a hardware source, but if you're using it to tune (for example) 
> a freq-xlating FIR filter, there's a disagreement on semantics. One could run 
> the Frequency Sink in relative mode in this case. But it seems like there 
> should be more flexibility in dealing with the contents of async messages, in 
> situations where the message tag ("freq" in this case) could have semantics 
> that not everyone who takes such a tag might agree on. 
> 
> There've been long discussions on this subject, at least one of them at a dev 
> call. In general, the message format is of the (index, value) format. For the 
> case of the xlating FIR, all you need to do is change your x-axis to make the 
> center freq 0, and you're good. Getting tags and PMTs right is still a 
> learning process for all of us, but we didn't want to add loads of extra 
> settings into the QT sink just so we could get the tags into any format we 
> liked.
> It should, I think, also be possible to turn such tags into variable settings 
> in GRC, but I couldn't find any way to do so. 
> 
> H... maybe some block that would work with with the probes could do that. 
> Would have to be written, though.
> 
> M
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

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

 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2]
http://gnuradio.org/doc/doxygen/classgr_1_1qtgui_1_1freq__sink__c.html
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Click-to-tune in Qt GUI Frequency SInk

[Tom Rondeau]

On Mon, Mar 23, 2015 at 7:12 AM,  wrote:

>  Indeed, if one uses relative, rather than absolute frequencies in the Qt
> Frequency sink, everything is wonderful.
>
> But I think there are, as you observe, deeper questions about the desired
> semantics of async messages of this type.
>
> An advantage to the "sets a variable" implementation on the WX GUI side,
> is that said variable can be manipulated and scaled as appropriate,
> depending on who is consuming it.
>
> It's early days for the async-message subsystem within GR, and we are
> learning as we're going.  No surprises
>

I also just want to point out that the format of the messages is described
in the manual

http://gnuradio.org/doc/doxygen/classgr_1_1qtgui_1_1freq__sink__c.html

See the Detailed Description section.

Tom



> On 2015-03-23 02:12, Martin Braun wrote:
>
> On 22.03.2015 19:26, Marcus D. Leech wrote:
>
> Just looking at the async message interface for Qt GUI Frequency Sink. The
> "freq" output (is that a PMT?) is always, it appears, in terms of "display"
> frequency. Which is cool if you're using the click-to-tune output to modify
> (for example) a hardware source, but if you're using it to tune (for
> example) a freq-xlating FIR filter, there's a disagreement on semantics.
> One could run the Frequency Sink in relative mode in this case. But it
> seems like there should be more flexibility in dealing with the contents of
> async messages, in situations where the message tag ("freq" in this case)
> could have semantics that not everyone who takes such a tag might agree on.
>
> There've been long discussions on this subject, at least one of them at a dev 
> call. In general, the message format is of the (index, value) format. For the 
> case of the xlating FIR, all you need to do is change your x-axis to make the 
> center freq 0, and you're good. Getting tags and PMTs right is still a 
> learning process for all of us, but we didn't want to add loads of extra 
> settings into the QT sink just so we could get the tags into any format we 
> liked.
>
> It should, I think, also be possible to turn such tags into variable
> settings in GRC, but I couldn't find any way to do so.
>
> H... maybe some block that would work with with the probes could do that. 
> Would have to be written, though.
>
> M
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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] CMA Equalizer

[Tom Rondeau]

On Mon, Mar 23, 2015 at 3:51 AM, Merry Dominic  wrote:

> Sir,
>
> What do the number of taps in the CMA equalizer block represent, I hope it
> is the channel size. Should it be the number of tap coefficients given for
> the variable 'taps' in the channel model block. If I give 'taps' in the
> channel model block (I am considering the basic awgn channel model block)
> as taps =[a1+jb1,a2+jb2,a3+jb3,a4+jb4], what should be the Num. Taps in the
> CMA equalizer block.I am using the polyphase clock synchronizer between the
> channel model block and the equalizer.
>
> Please help.Looking forward for your reply.
>
> Thanks
> Merry
>

Yes and no. The number of taps is to shape the equalizer's response
appropriately for the channel. Generally, we don't know anymore more than
some statistics about the channel and so we try to select the number of
taps in the filter according to that. It won't be perfect since channels
are always changing, so we try and balance the complexity of the algorithm
with the response to the channel. The more taps, the more accurate you get,
but at greater computational cost.

So no one can really answer this question for you.

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

Re: [Discuss-gnuradio] Click-to-tune in Qt GUI Frequency SInk

[mleech]

 

Indeed, if one uses relative, rather than absolute frequencies in the Qt
Frequency sink, everything is wonderful. 

But I think there are, as you observe, deeper questions about the
desired semantics of async messages of this type. 

An advantage to the "sets a variable" implementation on the WX GUI side,
is that said variable can be manipulated and scaled as appropriate,
depending on who is consuming it. 

It's early days for the async-message subsystem within GR, and we are
learning as we're going. No surprises 

On 2015-03-23 02:12, Martin Braun wrote: 

> On 22.03.2015 19:26, Marcus D. Leech wrote:
> 
>> Just looking at the async message interface for Qt GUI Frequency Sink. The 
>> "freq" output (is that a PMT?) is always, it appears, in terms of "display" 
>> frequency. Which is cool if you're using the click-to-tune output to modify 
>> (for example) a hardware source, but if you're using it to tune (for 
>> example) a freq-xlating FIR filter, there's a disagreement on semantics. One 
>> could run the Frequency Sink in relative mode in this case. But it seems 
>> like there should be more flexibility in dealing with the contents of async 
>> messages, in situations where the message tag ("freq" in this case) could 
>> have semantics that not everyone who takes such a tag might agree on.
> 
> There've been long discussions on this subject, at least one of them at a dev 
> call. In general, the message format is of the (index, value) format. For the 
> case of the xlating FIR, all you need to do is change your x-axis to make the 
> center freq 0, and you're good. Getting tags and PMTs right is still a 
> learning process for all of us, but we didn't want to add loads of extra 
> settings into the QT sink just so we could get the tags into any format we 
> liked.
> 
>> It should, I think, also be possible to turn such tags into variable 
>> settings in GRC, but I couldn't find any way to do so.
> 
> H... maybe some block that would work with with the probes could do that. 
> Would have to be written, though.
> 
> M
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

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

Re: [Discuss-gnuradio] How to use other modules in my out-of-tree module?

[Jeon]

Thanks, TOm.

Answer to my question.

gr::dvbt::reed_solomon d_rs(...) works.

No CMakeLists modification and other stuffs are needed.

Regards,
Jeon.

2015-03-20 22:36 GMT+09:00 Tom Rondeau :

> On Fri, Mar 20, 2015 at 4:07 AM, Jeon  wrote:
>
>> In my out-of-tree module (in develop)
>>
>> I want to use Reed-Solomon encoder and decoder from [gr-dvbt](
>> https://github.com/BogdanDIA/gr-dvbt)
>>
>> I've successfully installed gr-dvbt.
>>
>> In my code, it contains:
>>
>> #include 
>> #include 
>> #include 
>>
>> and variable declaration:
>>
>> reed_solomon::reed_solomon d_rs(rs_p, rs_m, gfpoly, phy.rs_n,
>> phy.rs_k, phy.rs_t2 / 2, phy.rs_s, blocks);
>>
>> and so on.
>>
>> When I build my module with `make` command, the following errors appear:
>>
>> gr-mymodule/lib/utils.cc: In function ‘void outer_encode(char*,
>> char*, tx_param&, phy_param&)’:
>> gr-mymodule/lib/utils.cc:170:3: error: ‘reed_solomon’ has not been
>> declared
>>reed_solomon::reed_solomon d_rs(rs_p, rs_m, gfpoly, phy.rs_n,
>> phy.rs_k, phy.rs_t2 / 2, phy.rs_s, blocks); // gr-dvbt
>>^
>>
>> I think I need to modify CMakeLists.txt in somewhere and somehow to tell
>> 'I will be using gr-dvbt', but I have no idea to do it.
>>
>> Does anyone have an idea for my problem?
>>
>> Regards,
>> Jeon.
>>
>
> I haven't tested this, just looked at the code, so not sure this is the
> full answer. You're using reed_solomon as the namespace, which it's not;
> it's the class name under the dvbt namespace. Try calling it like:
>
> dvbt::reed_solomon d_rs(...)
>
> You will have to link against the dvbt library in the CMakeLists.txt file
> (in the lib/ directory), but this is a compiler error, not a linker error.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CMA Equalizer

[Merry Dominic]

Sir,

What do the number of taps in the CMA equalizer block represent, I hope it
is the channel size. Should it be the number of tap coefficients given for
the variable 'taps' in the channel model block. If I give 'taps' in the
channel model block (I am considering the basic awgn channel model block)
as taps =[a1+jb1,a2+jb2,a3+jb3,a4+jb4], what should be the Num. Taps in the
CMA equalizer block.I am using the polyphase clock synchronizer between the
channel model block and the equalizer.

Please help.Looking forward for your reply.

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

Re: [Discuss-gnuradio] Fwd: AttributeError: 'module' object has no attri

[Ludwig Stephan (CR/AEH4)]

Thanks Tom for your immediate response. I re-created the blocks in my module 
and copied sources over from tagged_stream_to_pdu, which works not.
I cannot reproduce the described error anymore, which means the issue is solved 
for me. The diff between old and new code does not show any differences but the 
old block name was tagged_stream2pdu.

Nevertheless, thanks for your help..

Mit freundlichen Grüßen / Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication Technology 
(CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
www.bosch.com

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
stephan.ludw...@de.bosch.com

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. 
Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Dirk 
Hoheisel, Christoph Kübel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller
Von: trond...@trondeau.com [mailto:trond...@trondeau.com] Im Auftrag von Tom 
Rondeau
Gesendet: Freitag, 20. März 2015 17:58
An: Ludwig Stephan (CR/AEH4)
Cc: discuss-gnuradio@gnu.org
Betreff: Re: [Discuss-gnuradio] Fwd: AttributeError: 'module' object has no 
attri

On Fri, Mar 20, 2015 at 12:42 PM, Ludwig Stephan (CR/AEH4) 
mailto:stephan.ludw...@de.bosch.com>> wrote:
Hi Tom,

I have a similar problem. I added a pretty plain block, which uses #include 
 and changed my set() according to your description to
set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS PMT PDU)

All compiles well, but the same error as in this thread.

Do you have a clue, what I am missing?

Regards
Stephan

I haven't a clue. I just tried it and it worked fine.

To the impl.cc file, I added:

#include 
...
  gr::blocks::pdu::vector_type i = gr::blocks::pdu::float_t;
  size_t t = gr::blocks::pdu::itemsize(i);

And then I added BLOCKS to the GR_REQUIRED_COMPONENTS and it worked fine. 
Without the cmake changes, I get the same error, but otherwise, it worked as 
expected here.

Tom




>When you build an OOT module, it only knows to look for and link against the 
>GNU Radio runtime library. If you look in the top-level CMakeLists.txt file of 
>your project, you'll
> see a line (somewhere around line 113) that declares this:

> set(GR_REQUIRED_COMPONENTS RUNTIME)

> But now you are trying to use an FFT filter, which is in the GNU Radio filter 
> library (libgnuradio-filter). You need to tell the project to both find and 
> link against this library now,
> so change that line to:

> set(GR_REQUIRED_COMPONENTS RUNTIME FILTER)

> For future reference, nearly this exact problem is mentioned in out OOT 
> configuration tutorial:

> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig

> Tom

Mit freundlichen Grüßen / Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication Technology 
(CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
www.bosch.com

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
stephan.ludw...@de.bosch.com

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. 
Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Dirk 
Hoheisel, Christoph Kübel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller




___
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