Leo Yang | 24 Nov 14:00 2014

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)

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

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?





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("";)


while infinite == 1;

  # Grab predict doppler using UDP





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









Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
sreena p h | 24 Nov 10:34 2014

working with TCP source/sink


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


Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
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:
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:

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

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


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


Mostafa Alizadeh | 23 Nov 22:39 2014

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,

Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
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:


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


Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
Mike Willis | 22 Nov 16:25 2014

Problems with Gnuradio-Companion

Hi everyone


How does gnuradio-companion find and recognise blocks?



Why is it so damned difficult for a normal person to write and maintain a block?


I had developed a working block written which functioned fine, even in gnuradio-companion. I needed an extra parameter so I added this. I modified all the appropriate files that I know about in lib, include and so on to include the extra parameter input. The modified block compiles without errors and it installs and works fine. I have done a sudo ldconfig. It even works and so do previous Python scripts that use it.


BUT Gnuradio Companion absolutely and completely refuses to find it. Error – block key not found in platform. Its not in the list of blocks, its just gone.


Is the XML file there? yes. Is it properly configured? Yes. Are all the other files in the right places? Yes – it would appear so by comparison with other blocks. No doubt there is some config file somewhere expecting my block to have one less parameter hiding in a directory with a curious name where its obvious to developers but not to mere mortals. Has GRC has looked is some such place, noted a difference and silently ignored the block completely? Three hours I have been bashing away at this and have got nowhere.


Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
swx z | 22 Nov 14:04 2014

plateau detectors

Hello all:
              I have read the code of "Schmidl & Cox synchronisation".And I find the code use the plateau detectors.It shows that the code will output 1 at the middle of the plateau.Why not in the first place of the plateau instead of in the middle of the plateau?
             Thank you very much.
Best regards,
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
Mike Willis | 22 Nov 12:04 2014

Saving to file with a timestamp

I have a flowgraph working that I want to use to save data to a file. I would like the file name to update each time, ideally with a time stamp as part of the name. Is this possible directly from GRC of will I need to write a block?



Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
Alexander Tudor | 21 Nov 21:27 2014

sdr-iq on mac 10.7 or 10.9


My installation consists of: a) OSX 10.9 or 10.7 b) gnuradio 3.7.x installed through mac ports, c) osmosdr (because of its support for SDR-IQ within gnu radio companion) installed through mac ports.
My goal is to use SDR-IQ within gnu radio companion but wanted to proceed in smaller steps, the least of which, I was told, was to use gqrx or osmosdr_fft.

I started with 10.9 and, as per FTDI instruction, removed Apple's serial driver (the rationale being, I think, to avoid conflict with port access elsewhere). I then proceeded to install the D2XX libraries from FTDI with the expectations that
something like gqrx would work. It did not, as it kept expecting /dev/tttyUSB, which did not exist (I believe that D2XX, provides, somehow, direct access to the USB port). Somebody suggested directly setting DYLD_INSERT_LIBRARIES such that gqrx would find them. On 10.9 I have also tried to connect SDRDx through SDR-xx Server, all to no avail.

I had then repeated this experiment on a 10.7 machine and SDRDx was working through the SDR-xx Server and I could connect a 10.9 SDRDx client to the 10.7 SDR-xx Server. gqrx does not work on 10.7 however.

As I wrote above my goal is to connect the SDR-IQ directly to the machine that runs 10.9 and to use osmosdr's block as a source within gnu radio companion.

At this point I do not know how to further proceed.

Any ideas or clarifications on misunderstandings I may have about what I am trying to achieve appreciated!

Thank you,

Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
Leo Yang | 21 Nov 18:38 2014

Question about Plotting the Spectrum(Power against frequency) with usrp_sense.py

Question about the spectrum plot of the usr_sense.py:
I have modified the old usrp_spectrum_sense.py to fit the latest version of
gnuradio, and now I can run the program and export the m.data into a txt
file, I wonder how to plot the dynamic graph of power against frequency for
the visualization of the spectrum analyzer.
Any direction or examples will be very helpful for me. 

Thanks a lot 

here is the source code of usrp_spectrum_sense.py 

View this message in context: http://gnuradio.4.n7.nabble.com/Question-about-Plotting-the-Spectrum-Power-against-frequency-with-usrp-sense-py-tp51380.html
Sent from the GnuRadio mailing list archive at Nabble.com.