Sylvain Munaut | 26 Nov 10:38 2014
Picon

FFT scaling consistency

Hi,

Yesterday someone in the chat raised an interesing issue. The absolute
scale of the various FFT GUI sinks.

If you take:

[signal source ampl=1.0] -> [gui fft sink]

(use a source freq that fits exactly on 1 fft bin)

With complex + WXGUI it peaks at -3dB
With complex + QTSink it peaks at -9dB
With float + WXGUI it peaks at -9dB
With float + QTSink it peaks at -15dB

So basically:

 - The WXGui + Complex should be 0dB IMHO.
   A complex cosine of ampl 1.0 should be our 'absolute' reference for 0dB

 - QTSink is always 6dB lower
   -> That doesn't sound logical, they should just match. GUI
selection should have no influence on the absolute reading when
working with purely synthetic data.

 - Float is always 6dB lower than complex
   -> I'm torn on this one ... can't decide :p
      If you integrate the energy (x^2) over one cycle between a
complex cosine and a float cosine, you get half the energy. So this
(Continue reading)

Felix W. | 25 Nov 18:15 2014

Running out of memory during BER simulations

Hi list,

I'm currently performing BER measurements for an IEEE 802.15.4 system. In order to do so, I have created a flowgraph (in GRC/python) that is executed for different SNR values until a certain number of bits has been processed. Between every run, I call tb.stop() followed by tb.wait(). Unfortunately, after a few runs (around 20), I get the following error message:

gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

sysctl says:
kernel.shmall = 2097152
kernel.shmmax = 2147483648

I don't really understand why this happens as my memory usage is very stable and < 20% of total RAM throughout the simulation. In my understanding, calling, tb.stop() and tb.wait() should delete anything the flowgraph allocated before. I also noticed that the block numbers (which are displayed because I call set_min_output_buffer() ) are monotonically increasing during the simulation even though the top block is stopped multiple times. This might be completely unrelated, however it indicates that my understanding might not be correct.

Any ideas?

--Felix Wunsch

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
West, Nathan | 25 Nov 17:58 2014

Re: Install: qa_volk_test_all fails

On Tue, Nov 25, 2014 at 10:50 AM, West, Nathan
<natw <at> ostatemail.okstate.edu> wrote:
> On Tue, Nov 25, 2014 at 7:46 AM, madengr <rfengr00 <at> me.com> wrote:
>>
>> Try my other suggestion if the above does not work.  My guess is the VOLK
>> tests won't work since this is your first time installing gnuradio, and you
>> have not run the volk_profile. In which case you need to bootstrap by
>> installing it first, run volk_profile, then you can run the tests.
>>
>>
>> Lou
>

Forgot to hit reply-all the first time.

I'm not sure where this suggestion is coming from, but installing VOLK
has nothing to do with the QA. There is no bootstrapping VOLK, in fact
the there's something like a 99% overlap between code executed when
runing 'make test' on VOLK and volk_profile.

If you have experience where make test fails on VOLK, but passes
after installing I would like to hear about it because it's the sign of a bug.

Nathan
Mostafa Alizadeh | 25 Nov 07:37 2014
Picon

Re: GNURadio retrictions

Hi Marcus,

On Mon, Nov 24, 2014 at 1:33 AM, Marcus Müller <marcus.mueller <at> ettus.com> wrote:
Hi Mostafa,

On 11/23/2014 10:39 PM, Mostafa Alizadeh wrote:
> I just figured
> out the following limitation of GNURadio's framework that I want to diacuss
> them to clarify whether I'm wrong or not:
>
> 1- For general blocks with multiple output ports, there is a problem with
> the amount of producing items when the general work routine just gives you
> the "maximum" available number of output items for all output ports, and
> also set_output_multiple or other functions like set_alignment dealing with
> all output ports rather than individual ones. So if one wants to produce
> items on the output ports with large different numbers, such as 100 items
> on one port and 2000 items on the other one, the scheduler will fail to
> manage this high "diverse" ports.
Ok, I think this needs some explanation. What does "fail to manage"
imply exactly?
Generally, I think if you're having something like a block that produces
2000 samples on one, and 100 on another, but does not have a fixed rate
between in- and output, this sounds you like, from a logical point of
view as much as by performance considerations, be better of using messages.


That's a good idea ( using messages instead)!
 
But I think if you illustrate more closely, it's likely we can figure
out where the problem lies.
>
> 2- The scheduler jumps through different blocks before finishing the work
> routine's job which causes some problems.
No, it doesn't. At least the GNU Radio scheduler won't interrupt a work
function

I believe in what I see in GNURadio! It forsakes the work's routine somewhere in amidst of it!!

 
Ok, so here's the problem I have with your phrasing: you use
"scheduler", and I *assume* you mean the GNU Radio scheduler.

It's the thread-per-block scheduler, which executes multiple blocks
/simultaneously/.

Underneath, of course, lies a runtime environment (boost threads), which
uses underlying threading libraries (on unixoids usually pthreads),
which use the underlying operating system's multithreading routines
(aka. the OS's scheduler) , which will execute blocks interleaved
(depending on system architecture, number of CPUs etc).


OK, these information doesn't solve the problem at least for me who don't know anything about boost.
 
>  For example, consider the below
> code which is placed somewhere in the work (general_work ):
>
> """""""""""""""""
> memcpy (out, temp, n_out_produced * sizeof(gr_complex);
>
> produce(0, n_out_produced);
>
> add_item_tag(0, nitems_written(0), ... , ... );
> """""""""""""""""
>
> So if we change the order of the code like this:
>
> """""""""""""""""
> memcpy (out, temp, n_out_produced * sizeof(gr_complex);
>
> add_item_tag(0, nitems_written(0), ... , ... );
>
> produce(0, n_out_produced);
> """""""""""""""""
Obviously, calling produce() increments the value that nitems_written()
should return! (nitems_written is "number of produced samples")
So these are two very different programs, semantically.
>
> In the second case there is no problem with tagging process, although in
> the first case the scheduler may jump out of this block right after calling
> produce function,
No, he doesn't ;) you've just written buggy code. 
Greetings,
Marcus

I swear that I wrote a clean code :), I see what I see.

This is also so complicated, I forgot to add, that sometime calling the produce() function before add_item_tag() increments the nitems_written() and sometime doesn't!!!! why??


Best, 
Mostafa
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
madengr | 25 Nov 04:53 2014

Re: Install: qa_volk_test_all fails

Run volk_profile then rerun the tests.

Lou

Cocacola93 wrote
> On Ubuntu 14.04LTS 32bit,  I tried installing using gnuradio-3.7.5
>      The build completed, but several of the build tests fail 
> 98  % tests passed,4 test failed out of 193
> 
> The following tests FAILED:
> 1 - qa_volk_test_all (Failed)
> 31 - qa_udp_source_sink (Failed)
> 181-qa_trellis (Failed)
> 187-qa_codec2_vocoder (Failed)
> Errors while runnnig CTest
> I hope you can help me! Thankyou!

--
View this message in context: http://gnuradio.4.n7.nabble.com/Install-qa-volk-test-all-fails-tp51420p51422.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Leo Yang | 24 Nov 14:00 2014
Picon

Received Signal Power question

 I found one modified example from usrp_spectrum_sense.py which mentioned the
power and noise calculation, could u plz help me figure out how it works? 

        for i_bin in range(bin_start, bin_stop):

            center_freq = m.center_freq
            freq = bin_freq(i_bin, center_freq)
            #noise_floor_db = -174 + 10*math.log10(tb.channel_bandwidth)
            noise_floor_db = 10*math.log10(min(m.data)/tb.usrp_rate)
            power_db = 10*math.log10(m.data[i_bin]/tb.usrp_rate)
-noise_floor_db

--
View this message in context: http://gnuradio.4.n7.nabble.com/Received-Signal-Power-question-tp51409.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Mike Willis | 24 Nov 11:15 2014
Picon

Re: linking Gnuradio and Gpredict ?

I know this is going back a bit but I would like to do the same thing for my Gnuradio satellite ground station. I was actually tempted to compile satellite tracking into a Gnuradio block. One you could simply use in a flowchart without any of the messing about with XMLRPC but like my new hexagonal wheel project, with active compensatory suspension, it might be better to use what’s already there.

 

Did anyone do this? And, how difficult would it be in practice to develop a native block that either contains predict, or accesses it? Possibly not very difficult at all and maybe already done?

 

Mike

 

 

On 22/07/13 12:31, M Dammer wrote:

 

Is it possible to link Gnuradio and Gpredict ? I want to use Gpredict as

tracker controlling the antenna position and to pass doppler corrected

frequency data to Gnuradio.

 

In a word, yes.

 

Can be very simple. I did it by using an XML Server in the flow graph,

and wrote a quick XML client (actually I "stole" most of it from an

example), and sent the doppler info from predict via a variable.

 

doppler info was received from predict using some code to query predict

using UDP. I think I just used nc to send the UDP query to predict,

recovered the shift from the reply, and sent it back to the XML Server

running within the flow graph.

 

Unfortunately I can't find my actual code right now, but I literally

copied an example, and added the UDP Predict clients bit. It went

something like this pseudo code (Yes, this is a mix of shell,and

python, and you need to re-write the getting doppler from predict yourself, but you get the idea, and should give you enough)

 

import time

import sys

from socket import *

import xmlrpclib

import binascii

 

s = xmlrpclib.Server("http://192.168.39.74:8081";)

infinite=1

while infinite == 1;

  # Grab predict doppler using UDP

  DOPPLER=`nc -u -s 2 $PREDICTHOST GET_DOPPLER $NORAD_NUMBER`

  s.set_doppler_shift($DOPPLER)

  time.sleep(1)

 

The variable (lets call it doppler_shift) exists in the flowgraph,

and was multiplied appropriately and applied to the centre frequency of

a FIR filter.

 

You can pretty much pass any information you want in and out of a flow

graph using a XML Server/Client pair. I've done TX/RX switching, and

am currently working on telemetry decoding/display

 

 

Iain

 

 

 

 

 

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
sreena p h | 24 Nov 10:34 2014
Picon

working with TCP source/sink

Hi

I would like to work with transmission of signals with sound card of laptop. I would like to know the working of TCP sink/socket . I am attaching a transceiver system that i tried from a project published in the net. But I couldn't enter any data at the TCP source, Please help me on how this block work..

Regards 

Sreena
 
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
jkkjjkjk kjjkjkjkj | 23 Nov 23:10 2014

Patching airprobe to compile with GNURadio 3.7

Hey, I've spent the last couple of days trying to get airprobe rtl GSM software to work with the new GNU Radio.
I made a patch to grcompat to fill in the missing functions:
https://github.com/genjix/grcompat
And have got ported the gsm module for gsm-receive/src/lib/ to work. And I've ported gsm_receive_rtl for
all the changes in module structure in GNU Radio. Now the program opens but I'm stuck at one last step.

Here is the line giving me difficulty:
https://github.com/genjix/airprobe/blob/master/gsm-receiver/src/python/gsm_receive_rtl.py#L98

#self.connect(self.src, self.tuner, self.interpolator, self.receiver, self.converter, self.output)
self.connect(self.src, self.tuner, self.interpolator)

I've commented the original which gives me this error:

configure_receiver
Traceback (most recent call last):
File "./gsm_receive_rtl.py", line 232, in <module>
tb = top_block()
File "./gsm_receive_rtl.py", line 99, in __init__
self.connect(self.src, self.tuner, self.interpolator, self.receiver)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 131, in connect
self._connect(points[i-1], points[i])
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 141, in _connect
(dst_block, dst_port) = self._coerce_endpoint(dst)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 152, in _coerce_endpoint
raise ValueError("unable to coerce endpoint")
ValueError: unable to coerce endpoint

Here is the source for the self.receiver type (a custom block for GSM receiving):

https://github.com/genjix/airprobe/blob/master/gsm-receiver/src/lib/gsm_receiver_cf.cc#L305

Any clues? What is the problem with gsm_receiver_cf that GNU Radio gives that error? It used to work with 3.6...

Thanks

 		 	   		  
Mostafa Alizadeh | 23 Nov 22:39 2014
Picon

GNURadio retrictions

Hello GNURadioers!

I've been working with GNURadio since about one year ago. I just figured out the following limitation of GNURadio's framework that I want to diacuss them to clarify whether I'm wrong or not:

1- For general blocks with multiple output ports, there is a problem with the amount of producing items when the general work routine just gives you the "maximum" available number of output items for all output ports, and also set_output_multiple or other functions like set_alignment dealing with all output ports rather than individual ones. So if one wants to produce items on the output ports with large different numbers, such as 100 items on one port and 2000 items on the other one, the scheduler will fail to manage this high "diverse" ports.

2- The scheduler jumps through different blocks before finishing the work routine's job which causes some problems. For example, consider the below code which is placed somewhere in the work (general_work ):

"""""""""""""""""
memcpy (out, temp, n_out_produced * sizeof(gr_complex);

produce(0, n_out_produced);

add_item_tag(0, nitems_written(0), ... , ... );
"""""""""""""""""

So if we change the order of the code like this:

"""""""""""""""""
memcpy (out, temp, n_out_produced * sizeof(gr_complex);

add_item_tag(0, nitems_written(0), ... , ... );

produce(0, n_out_produced);
"""""""""""""""""

In the second case there is no problem with tagging process, although in the first case the scheduler may jump out of this block right after calling produce function, so the position of the tagging which is " nitems_written(0)" will change to the new value. Suppose in the next call to the first code, after calling produce function, the add_item_tag is called and the item is tagged on "nitems_written(0)" position which is the same as the previous call. So these two consecutive tags are placed on the same position in the stream. Why is this happening? This is just because before finishing the job of this work routine, scheduler jumps somewhere else.

Please help me find the rational reason!

Thanks in advance,
Alizadeh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Louis Brown | 23 Nov 04:24 2014

QT GUI Time Sink text scale bug


Can anyone confirm the QT GUI Time Sink has a time scale text bug when working at low sample rates in 3.7.6git-188-gf60cd24f?  Please see below:

https://dl.dropboxusercontent.com/u/49570443/qt_time_scale_grc.png
https://dl.dropboxusercontent.com/u/49570443/qt_time_scale_plot.png
https://dl.dropboxusercontent.com/u/49570443/qt_time_scale.grc

Plot text should be "ms" instead of "sec".  No show stopper; just confused me when working with very low rates.

Thanks,
Lou

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Gmane