Re: [Discuss-gnuradio] GnuRadio: Clock Recovery MM: imu out of bounds

[Marcus Müller]

Hi Michael,

so, this having sat on my "what the hell, I need to look at this" list
for the weekend:
I can't reproduce the behaviour, but that might simply have the cause of
me using white noise instead of your recording. Could you share that?

I have two hypotheses and one observation so far:
The observation is that in many places where we want to get the closest
int to a float, we use stuff like int imu= rint(mu*NSTEPS), which is
wrong in respect to the return value (double), the parameter type
(double) and in most cases also the side effects (rint is the version of
nearbyint that sets error flags, but we don't check them). We should use
something else; that's an overhaul of existing code that'll have to be
done another day.

So first hypothesis:
It's your signal that will suffice for us to reproduce the error. That's
the "good" case, because then one can actually inspect what goes wrong here.

Second hypothesis:
Based on above observation and VirtualBox' history of delicate floating
point bugs, this might get a bit more involved, especially since
floating point exception registers are involved, which historically were
hard to properly multithread/make ISR save; maybe the overhaul mentioned
above would solve the issue, though.

Best regards,
Marcus

On 21.08.2015 08:00, Michael B wrote:
> Hi Tom,
>
> Thanks for your help. I've adapted the sample rate of the result
> coming out of the low-pass filter now. However, if I decimate much
> further, my signal becomes a bit too weak I think.
> New chart:
> http://imgur.com/mbt288s,etHbYLT#0
>
> New result:
> http://imgur.com/mbt288s,etHbYLT#1
>
> Is this a better approach?
> The initial error still persists though.
>
> Regards
>
>
>
>
>  
>
>
> 
> From: mibo...@hotmail.com
> To: t...@trondeau.com
> Date: Thu, 20 Aug 2015 09:09:42 +0200
> CC: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GnuRadio: Clock Recovery MM: imu out
> of bounds
>
> Hi Tom,
>
> Thanks for your answer. That's indeed something that I need to think
> about more. However, as I understand it, the samples per symbol rate
> is equal to (samp_rate / data_rate). My sample rate is 500k, and my
> data rate (i think) is only around 100 or 200. See this figure of my
> (cleaned) signal:
>
> http://imgur.com/8pNqCop
>
> You see that it takes approximately 10 ms to transmit one symbol. This
> means 100 symbols per second. As I have 500k samples per second, this
> means 5k samples per symbol, right?
>
> However, I have tried setting the samples per symbol to 4, just to
> try, and the 'out of bounds' error still persists.
>
> Regards,
> Michael
>
>  
>
>
> 
> From: t...@trondeau.com
> Date: Wed, 19 Aug 2015 09:41:19 -0400
> Subject: Re: [Discuss-gnuradio] GnuRadio: Clock Recovery MM: imu out
> of bounds
> To: mibo...@hotmail.com
> CC: discuss-gnuradio@gnu.org
>
> On Wed, Aug 19, 2015 at 2:51 AM, Michael B  > wrote:
>
> I have created a flowgraph, based on an example of Michael Ossmann
> ,
> which takes in a signal, and should output bits.
>
> I need to use the clock recovery MM block, which I do not fully
> understand yet. However, after reading some blogposts, I am quite
> sure that I can leave most of the settings default, except for the
> Omega one. Here's my flowgraph:
>
>
> http://imgur.com/pHRXnZu
>
> When running this flowgraph, it gives me the following error:
>
> /thread[thread-per-block[5]:]:
> mmse_fir_interpolator_ff: imu out of bounds./
>
>
>
> While searching, I stumbled upon this piece of code
> 
> 
>  in
> the source of GnuRadio:
>
>
> /int imu = (int)rint(mu * NSTEPS);  
>   if((imu < 0) || (imu > NSTEPS)) {
> throw std::runtime_error("mmse_fir_interpolator_ff: imu out of
> bounds.\n");
>   }/
>
>
> So, I suspect it is not due to my Omega setting (which might be
> wrong, I have to play with that setting), but that it is due to my
> Mu setting, which is just the default (0.5). However, I understand
> that Mu needs to be between 0 and 1, so I do not really understand
> what the problem is. Anyone who does?
>
> Environment details:
>
>   * GNU Radio Companion 3.7.7.1
>   * Running a GNU Radio live DVD in a virtual machine (VirtualBox
> 4.2.12) on Windows 7.
>   * Using Volk machine: ssse3_64
>
>
> Michael,
>
> I don't have an answer, but I can say where you're doing something
> wrong. You're samples/symbol (samp_per_sym) is definitely /not/ 2.5k.
> That's a massively oversampled signal and can't be right. You need to
> think what's the sampling 

Re: [Discuss-gnuradio] Noob question 1

[Henk]

Hi Jan
Believe me, I am reading the tutorials, also the youtube lessons 
https://www.youtube.com/watch?v=N9SLAnGlGQs


But for me it is easier to understand basics when there is a basic 
working layout available. There is so much about GNURADIO

out there that a noob also needs some help with the help. (lol).

I am not a technician, developer or electronic engineer so the learning 
curve is steep.


Thanks for your replay and links.

When the RTL works I will post the layout here for others.

Best regards

Henk
www.sterrenwachtleeuwarden.nl 


Op 7-9-2015 om 10:47 schreef Jan Krämer:

Hi Henk,

I suggest you start with the guided GNU Radio Tutorials [1]. They 
contain the basics to work with GNU Radio.
In Tutorial 6 it is explained how to use a hardware source (USRP, RTL 
Dongle) with the audio sink [2]. But I suggest finishing the other 
tutorials first if you have no experience with GNURadio.


Cheers and happy hacking,
Jan

[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
[2] 
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Hardware_Considerations


2015-09-07 10:03 GMT+02:00 12henk12 >:


Hello all
4 weeks ago did my first steps into Linux Ubuntu.
I am trying to get the RTL-Dongel to work but still not succeded
in that,
Time to ask some help.
There is a image with pre-installed drivers and GNU-Radio companion,
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
I have downloaded that and put it on a USB stick. Works fine.

In the terminal I enter rtl_sdr -t and the RTL-dongel is found and
it works.
Then I start GNUradio companion, it is version 3.7.7.1. The RTL is
found in
the sources.
But the radio has a blue output and the audio-sink a orange one.
In the
Help-doks it says that this is because of the datatype
but I cant change that anywhere. The dongel properties-block gives
"complex
float 32".

Can you help me getting it to work? Only with a working system I
can go
further learning.

Thanks

Henk
www.sterrenwachtleeuwarden.nl 



--
View this message in context:
http://gnuradio.4.n7.nabble.com/Noob-question-1-tp55832.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] Noob question 1

[12henk12]

Hello all
4 weeks ago did my first steps into Linux Ubuntu.
I am trying to get the RTL-Dongel to work but still not succeded in that,
Time to ask some help.
There is a image with pre-installed drivers and GNU-Radio companion,
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
I have downloaded that and put it on a USB stick. Works fine.

In the terminal I enter rtl_sdr -t and the RTL-dongel is found and it works.
Then I start GNUradio companion, it is version 3.7.7.1. The RTL is found in
the sources.
But the radio has a blue output and the audio-sink a orange one. In the
Help-doks it says that this is because of the datatype
but I cant change that anywhere. The dongel properties-block gives "complex
float 32".

Can you help me getting it to work? Only with a working system I can go
further learning.

Thanks

Henk
www.sterrenwachtleeuwarden.nl 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Noob-question-1-tp55832.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] Noob question 1

[Marcus Müller]

Hi Henk,

the problem is that the RTL dongle (and any SDR peripheral) just gives
you the signal as it is in the air -- you will still have to demodulate
it to get audio!
Now, wild assumption: you want to listen to FM Radio for a start.
So:
* configure your audio sink to 44100 Hz sample rate
* use a WBFM receiver block with a quadrature rate of N*44100, and N as
decimation, feed the output (orange!) into the audio sink
* add a fractional resampler between source and WBFM receiver to match
N*44100 to a sampling rate the Dongle supports


Best regards,
Marcus

On 07.09.2015 10:03, 12henk12 wrote:
> Hello all
> 4 weeks ago did my first steps into Linux Ubuntu.
> I am trying to get the RTL-Dongel to work but still not succeded in that,
> Time to ask some help.
> There is a image with pre-installed drivers and GNU-Radio companion,
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
> I have downloaded that and put it on a USB stick. Works fine.
>
> In the terminal I enter rtl_sdr -t and the RTL-dongel is found and it works.
> Then I start GNUradio companion, it is version 3.7.7.1. The RTL is found in
> the sources.
> But the radio has a blue output and the audio-sink a orange one. In the
> Help-doks it says that this is because of the datatype
> but I cant change that anywhere. The dongel properties-block gives "complex
> float 32".
>
> Can you help me getting it to work? Only with a working system I can go
> further learning.
>
> Thanks
>
> Henk
> www.sterrenwachtleeuwarden.nl 
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Noob-question-1-tp55832.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

Re: [Discuss-gnuradio] Display Problem with QT GUI Vector Sink

[gnuradio]

The example is running without errors.
Is it possible, that the way my music_cf function is outputting the 
data, might cause some trouble?


Simon

Am 2015-09-04 21:45, schrieb Martin Braun:

There's an example for the vector sink, which doesn't seem to have that
issue. Can you confirm that? It's in gr-qtgui/examples.

M

PS: I had to locally fix the example, maybe you need to do that to, the
actual vector sink block was missing.

On 04.09.2015 01:57, gnura...@simonbiehl.de wrote:

Hi Martin,

averaging is disabled. Any further ideas?

Best regards,
Simon

Am 2015-09-03 18:49, schrieb Martin Braun:

The vector sink has an averaging option, is that on?

M
On 03.09.2015 02:25, gnura...@simonbiehl.de wrote:

Dear all,

I built an angle-of-arrival system using four Ettus USRP2. I'm 
facing a

problem when trying to display a vector containing the calculated
MUSIC-Spectrum using a “QT GUI Vector Sink”. The vector sink won't
display any data for the first two minutes, and then it is starting 
to

show very old values. When I use the block “Vector to Stream” and a
simple “QT GUI Time Sink” instead, the values are displayed 
immediately

without delay.

The block “music_cf” feeding the vector sink is a sync_decimator,
generating one vector of 181 elements for every 1000 input samples. 
I've
provided a shortened version of my c++ code in the attachment, 
without

the actual mathematics.

What could be the reason for this huge delay when using the “QT GUI
Vector Sink”? Is it a buffering problem?

Best regards,
Simon

Block Diagram:
http://fs1.directupload.net/images/150903/7cnqbzup.png


___
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] Display Problem with QT GUI Vector Sink

[Marcus Müller]

Hi Simon,

> Is it possible, that the way my music_cf function is outputting the
data, might cause some trouble?

181 floats isn't really a "round" itemsize, and since GNU Radio can only
build buffers that are multiple of 4KB (==4096B), I assume that you get
a large buffer (probably 4096 items of size 181*sizeof(float) each).
That per se is not a problem (maybe a loss of a few MB of RAM, but who
cares in this day and age?); but things get large, and as you can see,
latency can be pretty high. I remember seeing this a while back, when I
was trying large (as in 50dBbin) FFTs with the vector sink; I kind of
assumed visualizing a vector that is a couple of thousand times larger
than my screen had pixels in x-direction would have been what introduced
the latency, so I didn't look into it.

Attempt of building a test case, which might solve your issue, but is
vastly bad design (because it just copies twice):

music_cf->vector_to_stream->stream_to_vector->qt_vector_sink

Could you try that?

Next step, because this might be interesting: If you have both
performance counters enabled and Thrift/gr-controlport, you could have a
look at the ctrlport performance monitor, which would tell you things
like the average buffer fill, average work() run time, and variance of
these numbers.

Best regards,
Marcus


On 07.09.2015 12:44, gnura...@simonbiehl.de wrote:
> The example is running without errors.
> Is it possible, that the way my music_cf function is outputting the
> data, might cause some trouble?
>
> Simon
>
> Am 2015-09-04 21:45, schrieb Martin Braun:
>> There's an example for the vector sink, which doesn't seem to have that
>> issue. Can you confirm that? It's in gr-qtgui/examples.
>>
>> M
>>
>> PS: I had to locally fix the example, maybe you need to do that to, the
>> actual vector sink block was missing.
>>
>> On 04.09.2015 01:57, gnura...@simonbiehl.de wrote:
>>> Hi Martin,
>>>
>>> averaging is disabled. Any further ideas?
>>>
>>> Best regards,
>>> Simon
>>>
>>> Am 2015-09-03 18:49, schrieb Martin Braun:
 The vector sink has an averaging option, is that on?

 M
 On 03.09.2015 02:25, gnura...@simonbiehl.de wrote:
> Dear all,
>
> I built an angle-of-arrival system using four Ettus USRP2. I'm
> facing a
> problem when trying to display a vector containing the calculated
> MUSIC-Spectrum using a “QT GUI Vector Sink”. The vector sink won't
> display any data for the first two minutes, and then it is
> starting to
> show very old values. When I use the block “Vector to Stream” and a
> simple “QT GUI Time Sink” instead, the values are displayed
> immediately
> without delay.
>
> The block “music_cf” feeding the vector sink is a sync_decimator,
> generating one vector of 181 elements for every 1000 input
> samples. I've
> provided a shortened version of my c++ code in the attachment,
> without
> the actual mathematics.
>
> What could be the reason for this huge delay when using the “QT GUI
> Vector Sink”? Is it a buffering problem?
>
> Best regards,
> Simon
>
> Block Diagram:
> http://fs1.directupload.net/images/150903/7cnqbzup.png
>
>
> ___
> 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


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

Re: [Discuss-gnuradio] Noob question 1

[Ton Machielsen]

Hooking in on the discussion here. I struggle with something similar. I
know how to work gnuradio, that’s simple enough. What i want to learn more
about is how to configure my own SDR using gnuradio. So what the various
blocks are used for, when to use what block, etc.
I have experience LISTENING to an SDR using various devices, now i want to
BUILD one myself.
The final objective is to learn how to decode well known signals like the
various HAM radio protocols like PSK31, etc. I know that all has been done
before and the easy road is to take an existing flow graph, copy it and see
that it works. But to understand what is happening is a whole different
story.

So, without trying to hijack the thread, i am NOT looking for a gnuradio
manual, i am looking for documentation on how to USE gnuradio for signal
processing.

Thanks for the advice,

Ton.

On Mon, Sep 7, 2015 at 11:27 AM, Henk  wrote:

> Hi Jan
> Believe me, I am reading the tutorials, also the youtube lessons
> https://www.youtube.com/watch?v=N9SLAnGlGQs
>
> But for me it is easier to understand basics when there is a basic working
> layout available. There is so much about GNURADIO
> out there that a noob also needs some help with the help. (lol).
>
> I am not a technician, developer or electronic engineer so the learning
> curve is steep.
>
> Thanks for your replay and links.
>
> When the RTL works I will post the layout here for others.
>
> Best regards
>
> Henk
> www.sterrenwachtleeuwarden.nl
>
>
> Op 7-9-2015 om 10:47 schreef Jan Krämer:
>
> Hi Henk,
>
> I suggest you start with the guided GNU Radio Tutorials [1]. They contain
> the basics to work with GNU Radio.
> In Tutorial 6 it is explained how to use a hardware source (USRP, RTL
> Dongle) with the audio sink [2]. But I suggest finishing the other
> tutorials first if you have no experience with GNURadio.
>
> Cheers and happy hacking,
> Jan
>
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
> [2]
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Hardware_Considerations
>
> 2015-09-07 10:03 GMT+02:00 12henk12 :
>
>> Hello all
>> 4 weeks ago did my first steps into Linux Ubuntu.
>> I am trying to get the RTL-Dongel to work but still not succeded in that,
>> Time to ask some help.
>> There is a image with pre-installed drivers and GNU-Radio companion,
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>> I have downloaded that and put it on a USB stick. Works fine.
>>
>> In the terminal I enter rtl_sdr -t and the RTL-dongel is found and it
>> works.
>> Then I start GNUradio companion, it is version 3.7.7.1. The RTL is found
>> in
>> the sources.
>> But the radio has a blue output and the audio-sink a orange one. In the
>> Help-doks it says that this is because of the datatype
>> but I cant change that anywhere. The dongel properties-block gives
>> "complex
>> float 32".
>>
>> Can you help me getting it to work? Only with a working system I can go
>> further learning.
>>
>> Thanks
>>
>> Henk
>> www.sterrenwachtleeuwarden.nl
>>
>>
>>
>> --
>> View this message in context:
>> http://gnuradio.4.n7.nabble.com/Noob-question-1-tp55832.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Volk: __cpuid_count() for MSVC

[Gisle Vanem]

I noticed since last time (a year ago) I tried building
Volk using MSVC v16, the volk_cpu.tmp.c now uses the
gcc-centric function '__cpuid_count()' which MSVC doesn't
have.

I'm not really sure if the below patch is correct. But I
assume (from looking at gcc 5.1's source) that the ECX should
be loaded with the 'count' value. So could it be patched into
something like this?

--- a/volk/tmpl/volk_cpu.tmpl.c  2015-09-01 13:52:53
+++ b/volk_cpu.tmpl.c 2015-09-07 13:44:25
@@ -71,8 +71,16 @@

 static inline unsigned int cpuid_count_x86_bit(unsigned int level, unsigned int count, unsigned int reg, unsigned int 
bit) {

 #if defined(VOLK_CPU_x86)
+#if defined(_MSC_VER) && defined(HAVE_INTRIN_H)
+  int regs[4];
+  __cpuidex(regs, level, count);
+#elif defined(__GNUC__)
 unsigned int regs[4];
 __cpuid_count(level, count, regs[0],  regs[1],  regs[2], regs[3]);
+#else
+  #error No __cpuid()!
+#endif
 return regs[reg] >> bit & 0x01;
 #else
 return 0;


---

Just to let you know.

The docs on MSVC's __cpuidex() is here:
  https://msdn.microsoft.com/en-us/library/vstudio/hskdteyh(v=vs.100).aspx

--
--gv

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

[Discuss-gnuradio] Running flowgraphs from command line

[Patrick Krämer]

Hi everybody,

I installed GNURadio on a fresh machine with Mac OS X 10.10.5 via MacPorts. I 
now have 2 Python installs in /usr/bin, python2.6 and python2.7. Running 
flowgraphs with GRC is no problem. However, when trying to run a .py-file from 
the terminal, as suggested in the guided tutorial 3.1 („if else“) some modules 
are not found: 

Patricks-iMac:work patrick$ python if_else_mod.py
Traceback (most recent call last):
  File "if_else_mod.py", line 18, in 
from PyQt4 import Qt
ImportError: No module named PyQt4


Why does it work, when running the file from GRC? Is my terminal using the 
wrong python install? How could I change that? I also tried changing the path 
variable on my notebook a few days ago, when I ran into the same problem. But 
since I am new to python and the command line I obviously made a mistake so 
that at some point I could not start the GRC anymore. So your help is 
appreciated and needed. Couldn’t find a similar question in the archives.

Thank you.
Patrick


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

Re: [Discuss-gnuradio] Throttle block form wav files

[Murray Thomson]

On 7 September 2015 at 15:32, Kevin Reid  wrote:

> On Sep 7, 2015, at 5:42, Murray Thomson 
> wrote:
>
> >> 1. Using some method to force the wav source and audio source to match
> sample rates. Specifically, you could use a “Multiply by Matrix” block to
> replace the function of the Selector entirely: give it a matrix value of
> either ((1, 0),) or ((0, 1),) to select just one input.
> >
> > Can I make a multiply to matrix block have several inputs and one only
> output? If not, I was thinking on multiplying one of them by a constant
> block zero and then adding both outputs. Would this be a valid workaround?
>
> The number of inputs and outputs are determined by the dimensions of the
> matrix value entered. If you put in ((0, 1,),) with the comma (actually, I
> just remembered you can write [[0, 1]] as well and you don't have to worry
> about the extra comma (blame Python for that)) then it will have 2 inputs
> and 1 output. And, for example, if you wrote [[0], [1]], then it would have
> 1 input and 2 outputs.
>
> By the way, you can of course enter any numeric values to scale the inputs
> as you like, so for example you could use [[0, 0]] as a “mute” mode, or
> enter an arbitrary number as a gain control, if you wanted one.
>
> (If you did have an extra output that you couldn't get rid of, a null sink
> would be simplest there.)
>
> That's great help Kevin. Explains and solves my issue. Thanks!

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

Re: [Discuss-gnuradio] Throttle block form wav files

[Kevin Reid]

On Sep 7, 2015, at 5:42, Murray Thomson  wrote:

>> 1. Using some method to force the wav source and audio source to match 
>> sample rates. Specifically, you could use a “Multiply by Matrix” block to 
>> replace the function of the Selector entirely: give it a matrix value of 
>> either ((1, 0),) or ((0, 1),) to select just one input.
>  
> Can I make a multiply to matrix block have several inputs and one only 
> output? If not, I was thinking on multiplying one of them by a constant block 
> zero and then adding both outputs. Would this be a valid workaround?

The number of inputs and outputs are determined by the dimensions of the matrix 
value entered. If you put in ((0, 1,),) with the comma (actually, I just 
remembered you can write [[0, 1]] as well and you don't have to worry about the 
extra comma (blame Python for that)) then it will have 2 inputs and 1 output. 
And, for example, if you wrote [[0], [1]], then it would have 1 input and 2 
outputs.

By the way, you can of course enter any numeric values to scale the inputs as 
you like, so for example you could use [[0, 0]] as a “mute” mode, or enter an 
arbitrary number as a gain control, if you wanted one.

(If you did have an extra output that you couldn't get rid of, a null sink 
would be simplest there.)

-- 
Kevin Reid  


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

Re: [Discuss-gnuradio] Running flowgraphs from command line

[Kevin Hofschröer]

Hi Patrick,

I think I might have the answer, although Michael Dickens could
certainly provide better explanations and all that.

You need to check your environment variables. You can do that in the
command line by typing "env".
Normally you should see something like
"
PYTHONPATH=/opt/local/Library/Frameworks/Python.framework/Version/2.7/lib/python2.7/site-packages/:/opt/local/lib/:/usr/local/lib/
"
in the output.
Normally Macports should adapt your ~/.profile file in order to tell
your system where Macports put the stuff you installed.

If for some reasons that fails, your PYTHONPATH (in this case) will not
point to the correct directories.

If that indeed is the case, then you might insert some lines to your
~/.profile file, i.e.

"export
PYTHONPATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/:/opt/local/lib/:/usr/local/lib/:$PYTHONPATH"

and

"export PATH="/opt/local/bin:/opt/local/sbin:$PATH""

at the end of that file.

You might want to make sure that you can find PyQT4 yourself in those
given directories. For example my PyQT4 folder is under

"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages"

After you inserted those lines to your .profile, you just need to open a
new terminal, and you can again check via "env" if that worked out.

Regards,
Kevin


Am 07.09.15 um 18:29 schrieb Patrick Krämer:
> Hi everybody,
> 
> I installed GNURadio on a fresh machine with Mac OS X 10.10.5 via MacPorts. I 
> now have 2 Python installs in /usr/bin, python2.6 and python2.7. Running 
> flowgraphs with GRC is no problem. However, when trying to run a .py-file 
> from the terminal, as suggested in the guided tutorial 3.1 („if else“) some 
> modules are not found: 
> 
> Patricks-iMac:work patrick$ python if_else_mod.py
> Traceback (most recent call last):
>   File "if_else_mod.py", line 18, in 
> from PyQt4 import Qt
> ImportError: No module named PyQt4
> 
> 
> Why does it work, when running the file from GRC? Is my terminal using the 
> wrong python install? How could I change that? I also tried changing the path 
> variable on my notebook a few days ago, when I ran into the same problem. But 
> since I am new to python and the command line I obviously made a mistake so 
> that at some point I could not start the GRC anymore. So your help is 
> appreciated and needed. Couldn’t find a similar question in the archives.
> 
> Thank you.
> Patrick
> 
> 
> 
> 
> 
> ___
> 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] Noob question 1

[Henk]

My thoughts Ton,
I just made the FM receiver Marcus advised and as discribed in tutorial 6.
This week I will ask a few questions about the configuration of these 
blocks.

Understanding is the key word for me.

Thanks

Henk


Op 7-9-2015 om 13:38 schreef Ton Machielsen:
Hooking in on the discussion here. I struggle with something similar. 
I know how to work gnuradio, that’s simple enough. What i want to 
learn more about is how to configure my own SDR using gnuradio. So 
what the various blocks are used for, when to use what block, etc.
I have experience LISTENING to an SDR using various devices, now i 
want to BUILD one myself.
The final objective is to learn how to decode well known signals like 
the various HAM radio protocols like PSK31, etc. I know that all has 
been done before and the easy road is to take an existing flow graph, 
copy it and see that it works. But to understand what is happening is 
a whole different story.


So, without trying to hijack the thread, i am NOT looking for a 
gnuradio manual, i am looking for documentation on how to USE gnuradio 
for signal processing.


Thanks for the advice,

Ton.

On Mon, Sep 7, 2015 at 11:27 AM, Henk > wrote:


Hi Jan
Believe me, I am reading the tutorials, also the youtube lessons
https://www.youtube.com/watch?v=N9SLAnGlGQs

But for me it is easier to understand basics when there is a basic
working layout available. There is so much about GNURADIO
out there that a noob also needs some help with the help. (lol).

I am not a technician, developer or electronic engineer so the
learning curve is steep.

Thanks for your replay and links.

When the RTL works I will post the layout here for others.

Best regards

Henk
www.sterrenwachtleeuwarden.nl 


Op 7-9-2015 om 10:47 schreef Jan Krämer:

Hi Henk,

I suggest you start with the guided GNU Radio Tutorials [1]. They
contain the basics to work with GNU Radio.
In Tutorial 6 it is explained how to use a hardware source (USRP,
RTL Dongle) with the audio sink [2]. But I suggest finishing the
other tutorials first if you have no experience with GNURadio.

Cheers and happy hacking,
Jan

[1]
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
[2]

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

2015-09-07 10:03 GMT+02:00 12henk12 >:

Hello all
4 weeks ago did my first steps into Linux Ubuntu.
I am trying to get the RTL-Dongel to work but still not
succeded in that,
Time to ask some help.
There is a image with pre-installed drivers and GNU-Radio
companion,
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
I have downloaded that and put it on a USB stick. Works fine.

In the terminal I enter rtl_sdr -t and the RTL-dongel is
found and it works.
Then I start GNUradio companion, it is version 3.7.7.1. The
RTL is found in
the sources.
But the radio has a blue output and the audio-sink a orange
one. In the
Help-doks it says that this is because of the datatype
but I cant change that anywhere. The dongel properties-block
gives "complex
float 32".

Can you help me getting it to work? Only with a working
system I can go
further learning.

Thanks

Henk
www.sterrenwachtleeuwarden.nl




--
View this message in context:
http://gnuradio.4.n7.nabble.com/Noob-question-1-tp55832.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Marcus Müller]

Dave,
this might look strange to the afterworld, but:
Are you Ravi?

Best regards,
Marcus

On 08.09.2015 00:05, Dave Allen wrote:
> Yes, I tried that. Regarding the former question, I guess I have kept 
> all the files in that manner but I changed benchmark_tx.py and 
> uhd_interface.py files as far as I remember. Regarding the latter, I was 
> not able to give manually because I did not know as to exactly what 
> sampling rate and how many samples per symbol I can insert. Please help 
> with this. I have posted this in mailing list too.
>
> Thanks,
> Dave
>


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

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Dave Allen]

I am sorry. No

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Pybombs recipes submodule pointer update policy

[Ron Economos]

http://www.cgran.org/ isn't up to date either.

Ron

On 09/07/2015 07:29 PM, Chris Kuethe wrote:

I don't think there is an official policy. I do see that Tim updated
the recipes pointer a couple of days ago
(https://github.com/gnuradio/pybombs/commit/97fe3b3846dc1e10123fdc1c218ed94fa8dba63c).
.. I suppose I could write a tool to automate bugging people if the
pointer is more than a week behind the repo.

Generally I try keep all the recipes pointed at HEAD unless there's a
compelling reason to stick with a particular revision, so you can
update your code as often as you like and users should get the latest
version of your code.

On Sun, Sep 6, 2015 at 12:18 PM, Piotr Krysik  wrote:

W dniu 05.09.2015 o 20:01, Piotr Krysik pisze:

Hi all,

I have question for pybombs developers/maintainers:
Is there policy for updating recipes submodule pointer in the pybombs
repository?

Currently recipes submodule pointer is 29 days behind the head.

--
Best Regards,
Piotr Krysik



Hi,

In case of misunderstanding - I'm not trying to complain about your
work. Pybombs is great tool that simplifies a lot installation of GNU
Radio related projects. I need information as a developer of one of such
projects what are requirements for me in order to make fixes in recipes
related to my project appear faster in the main pybombs repository.

Best Regards,
Piotr

___
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] A small error in benchmark_tx file

[Dave Allen]

Thanks for the reply. I really appreciate it. I have subscribed to the 
mailing list. And in regard to my question, I have given the command and 
it has popped up this line

gnuradio-config-info --version
v3.7.7.1-198-g9e133ccb

I am not sure of what version the GNU Radio it can be? The command I 
have given was " ./benchmark_tx.py -f 2.435G " and it pops up the above 
error. But if I do the same thing for ./benchmark_rx.py -f 2.435G, it 
shows no error and waits for transmitter to transmit the packets.
And also can I please attach my benchmark files so that you might be 
able to view those.

Thanks,
Dave

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Running flowgraphs from command line

[Michael Dickens]

Hi Patrick - So what's happening is that with GRC, because it was
installed via MacPorts the MP version of Python is used. The terminal
only knows what you tell it via environment variables such as PYTHONPATH
(already suggested by Kevin Hofschröer) and PATH. In your case right
now, I'll bet that the PATH contains /usr/bin before /opt/local/bin (if
the latter is listed at all). If you do "which python", you'll see what
your shell is executing when you type "python" (again, better
/usr/bin/python [2.7 something]). Even if you add /opt/local/bin at the
start of PATH, you might still need to tell MP to select the version of
Python you want to use when you type "python" in the shell. You can list
the options port has via "port select --list python", and then select
Python 2.7 via "sudo port select python python27" if it not already
active. Combining this with making sure /opt/local/bin comes first in
PATH should solve your issue. Hope this helps! - MLD

On Mon, Sep 7, 2015, at 12:29 PM, Patrick Krämer wrote:
> I installed GNURadio on a fresh machine with Mac OS X 10.10.5 via
> MacPorts. I now have 2 Python installs in /usr/bin, python2.6 and
> python2.7. Running flowgraphs with GRC is no problem. However, when
> trying to run a .py-file from the terminal, as suggested in the guided
> tutorial 3.1 („if else“) some modules are not found:
>
> Patricks-iMac:work patrick$ python if_else_mod.py Traceback (most
> recent call last):  File "if_else_mod.py", line 18, in 
> from PyQt4 import Qt ImportError: No module named PyQt4
>
>
> Why does it work, when running the file from GRC? Is my terminal using
> the wrong python install? How could I change that? I also tried
> changing the path variable on my notebook a few days ago, when I ran
> into the same problem. But since I am new to python and the command
> line I obviously made a mistake so that at some point I could not
> start the GRC anymore. So your help is appreciated and needed.
> Couldn’t find a similar question in the archives.

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

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Dave Allen]

Yes, I tried that. Regarding the former question, I guess I have kept 
all the files in that manner but I changed benchmark_tx.py and 
uhd_interface.py files as far as I remember. Regarding the latter, I was 
not able to give manually because I did not know as to exactly what 
sampling rate and how many samples per symbol I can insert. Please help 
with this. I have posted this in mailing list too.

Thanks,
Dave

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Marcus Müller]

Ravi,

I don't understand -- are you Dave Allen?

Best regards,
Marcus

On 07.09.2015 23:59, Ravi Vemuri wrote:
> Hi all,
> I have been trying to send data between 2 USRP's from the benchmark_tx
> file only to observe that I have been receiving this error.
>
> Traceback (most recent call last):
>   File "./benchmark_tx.py", line 147, in 
> main()
>   File "./benchmark_tx.py", line 111, in main
> tb = my_top_block(mods[options.modulation], options)
>   File "./benchmark_tx.py", line 49, in __init__
> options.antenna, options.verbose)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 135, in __init__
> freq, gain, antenna)Hi all,
> I have been trying to send data between 2 USRP's from the benchmark_tx
> file only to observe that I have been receiving this error.
>
> Traceback (most recent call last):
>   File "./benchmark_tx.py", line 147, in 
> main()
>   File "./benchmark_tx.py", line 111, in main
> tb = my_top_block(mods[options.modulation], options)
>   File "./benchmark_tx.py", line 49, in __init__
> options.antenna, options.verbose)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 135, in __init__
> freq, gain, antenna)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 62, in __init__
> self._rate, self._sps = self.set_sample_rate(bitrate, sps)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 70, in set_sample_rate
> asked_samp_rate = bitrate * req_sps
> TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'
>
> I am unable to understand what this error means? I have tried to search
> in the Internet about this but found nothing relevant. Please advice as
> to what I can do?
>
> Thanks,
> Dave
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 62, in __init__
> self._rate, self._sps = self.set_sample_rate(bitrate, sps)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 70, in set_sample_rate
> asked_samp_rate = bitrate * req_sps
> TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'
>
> I am unable to understand what this error means? I have tried to search
> in the Internet about this but found nothing relevant. Please advice as
> to what I can do?
>
> Thanks,
> Dave
>
>
> ___
> 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] Why cant I increase signal by 1 hz at a time with high frequencies?

[Douglas Beonkey]

It seems that when I create a signal source block and try and view the
signal on a waterfall plot or FFT plot, I can not increase the signal by
a granularity of 1 Hz at higher starting frequencies.

Example:
If I create a signal source block with a starting frequency of 1.2 GHz,
and in the block have a variable slider added to the frequency (assume
the variable can slide between 0 and 1000), i must move the slider 120
or more steps before the signal shifts on the waterfall plot with a gap
of 120 or more hz.

Is there a way to move the signal by 1 hz regardless of how high or low
the signal source frequency is?

Signal block screen shots attached.

Attachments:
http://www.ruby-forum.com/attachment/11103/Signal_Source_Block.png
http://www.ruby-forum.com/attachment/11104/Signal_Increase_Hz.png


-- 
Posted via http://www.ruby-forum.com/.

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

[Discuss-gnuradio] How can I separate and count the IQ samples stored

[Julio Hector Aguilar Renteria]

How can I separate and count the IQ samples stored
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] A small error in benchmark_tx file

[Ravi Vemuri]

Hi all,
I have been trying to send data between 2 USRP's from the benchmark_tx
file only to observe that I have been receiving this error.

Traceback (most recent call last):
  File "./benchmark_tx.py", line 147, in 
main()
  File "./benchmark_tx.py", line 111, in main
tb = my_top_block(mods[options.modulation], options)
  File "./benchmark_tx.py", line 49, in __init__
options.antenna, options.verbose)
  File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 135, in __init__
freq, gain, antenna)Hi all,
I have been trying to send data between 2 USRP's from the benchmark_tx
file only to observe that I have been receiving this error.

Traceback (most recent call last):
  File "./benchmark_tx.py", line 147, in 
main()
  File "./benchmark_tx.py", line 111, in main
tb = my_top_block(mods[options.modulation], options)
  File "./benchmark_tx.py", line 49, in __init__
options.antenna, options.verbose)
  File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 135, in __init__
freq, gain, antenna)
  File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 62, in __init__
self._rate, self._sps = self.set_sample_rate(bitrate, sps)
  File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 70, in set_sample_rate
asked_samp_rate = bitrate * req_sps
TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'

I am unable to understand what this error means? I have tried to search
in the Internet about this but found nothing relevant. Please advice as
to what I can do?

Thanks,
Dave
  File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 62, in __init__
self._rate, self._sps = self.set_sample_rate(bitrate, sps)
  File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 70, in set_sample_rate
asked_samp_rate = bitrate * req_sps
TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'

I am unable to understand what this error means? I have tried to search
in the Internet about this but found nothing relevant. Please advice as
to what I can do?

Thanks,
Dave  #!/usr/bin/env python
#
# Copyright 2010,2011 Free Software Foundation, Inc.
# 
# This file is part of GNU Radio
# 
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
# 

from gnuradio import gr
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from optparse import OptionParser

# From gr-digital
from gnuradio import digital

# from current dir
from transmit_path import transmit_path
from uhd_interface import uhd_transmitter

import time, struct, sys

#import os 
#print os.getpid()
#raw_input('Attach and press enter')

class my_top_block(gr.top_block):
def __init__(self, modulator, options):
gr.top_block.__init__(self)

if(options.tx_freq is not None):
self.sink = uhd_transmitter(options.address, options.bitrate,
options.samples_per_symbol,
options.tx_freq, options.tx_gain,
options.antenna, options.verbose)
options.samples_per_symbol = self.sink._sps

elif(options.to_file is not None):
sys.stderr.write(("Saving samples to '%s'.\n\n" % (options.to_file)))
self.sink = gr.file_sink(gr.sizeof_gr_complex, options.to_file)
else:
sys.stderr.write("No sink defined, dumping samples to null sink.\n\n")
self.sink = gr.null_sink(gr.sizeof_gr_complex)

# do this after for any adjustments to the options that may
# occur in the sinks (specifically the UHD sink)
self.txpath = transmit_path(modulator, options)

self.connect(self.txpath, self.sink)

# /
#   main
# /

def main():

def send_pkt(payload='', eof=False):
return tb.txpath.send_pkt(payload, eof)

mods = digital.modulation_utils.type_1_mods()

parser = OptionParser(option_class=eng_option, conflict_handler="resolve")
expert_grp = 

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Marcus Müller]

Ha, ok, so I was mistaken regarding the version 3.7.7 is relatively recent!
Sanity check: the benchmark_tx and all other files in that directory
came with your version GNU Radio, and you did not download them
elsewhere, right?

Have you tried "./benchmark_tx --help", and then specifying things like
samples per symbol and sampling rate manually?

Best regards,
Marcus

On 07.09.2015 23:51, Dave Allen wrote:
> Thanks for the reply. I really appreciate it. I have subscribed to the 
> mailing list. And in regard to my question, I have given the command and 
> it has popped up this line
>
> gnuradio-config-info --version
> v3.7.7.1-198-g9e133ccb
>
> I am not sure of what version the GNU Radio it can be? The command I 
> have given was " ./benchmark_tx.py -f 2.435G " and it pops up the above 
> error. But if I do the same thing for ./benchmark_rx.py -f 2.435G, it 
> shows no error and waits for transmitter to transmit the packets.
> And also can I please attach my benchmark files so that you might be 
> able to view those.
>
> Thanks,
> Dave
>


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

[Discuss-gnuradio] ATSC decode successful on SDRPlay RSP

[Henry Barton]

Hi everyone. With help from Ron Economos, I managed to make ATSC decoding work 
using the SDRPlay RSP.
The big issue was that the RSP has a DC bar in the middle of the waterfall. 
Canceling it in the SDR program isn't enough; you have to get the latest driver 
and use the EXTIO options *in addition* to the Automatic DC cancellation in 
HDSDR.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs recipes submodule pointer update policy

[Chris Kuethe]

I don't think there is an official policy. I do see that Tim updated
the recipes pointer a couple of days ago
(https://github.com/gnuradio/pybombs/commit/97fe3b3846dc1e10123fdc1c218ed94fa8dba63c).
.. I suppose I could write a tool to automate bugging people if the
pointer is more than a week behind the repo.

Generally I try keep all the recipes pointed at HEAD unless there's a
compelling reason to stick with a particular revision, so you can
update your code as often as you like and users should get the latest
version of your code.

On Sun, Sep 6, 2015 at 12:18 PM, Piotr Krysik  wrote:
> W dniu 05.09.2015 o 20:01, Piotr Krysik pisze:
>> Hi all,
>>
>> I have question for pybombs developers/maintainers:
>> Is there policy for updating recipes submodule pointer in the pybombs
>> repository?
>>
>> Currently recipes submodule pointer is 29 days behind the head.
>>
>> --
>> Best Regards,
>> Piotr Krysik
>>
>>
> Hi,
>
> In case of misunderstanding - I'm not trying to complain about your
> work. Pybombs is great tool that simplifies a lot installation of GNU
> Radio related projects. I need information as a developer of one of such
> projects what are requirements for me in order to make fixes in recipes
> related to my project appear faster in the main pybombs repository.
>
> Best Regards,
> Piotr
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

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

Re: [Discuss-gnuradio] Why cant I increase signal by 1 hz at a time with high frequencies?

[Marcus D. Leech]

On 09/07/2015 10:33 PM, Douglas Beonkey wrote:

It seems that when I create a signal source block and try and view the
signal on a waterfall plot or FFT plot, I can not increase the signal by
a granularity of 1 Hz at higher starting frequencies.

Example:
If I create a signal source block with a starting frequency of 1.2 GHz,
and in the block have a variable slider added to the frequency (assume
the variable can slide between 0 and 1000), i must move the slider 120
or more steps before the signal shifts on the waterfall plot with a gap
of 120 or more hz.

Is there a way to move the signal by 1 hz regardless of how high or low
the signal source frequency is?

Signal block screen shots attached.

Attachments:
http://www.ruby-forum.com/attachment/11103/Signal_Source_Block.png
http://www.ruby-forum.com/attachment/11104/Signal_Increase_Hz.png


Using a signal source to produce a synthetic signal at 1.7GHz is simply 
not going to work, unless your sample-rate is 3.4GHz, which seems

  rather unlikely.

Normally in Gnu Radio, signals are represented in complex-baseband, 
leaving the hardware to move this up/down to the desired "on air"

  frequency.

Not sure what you're trying to accomplish, perhaps you could share a 
high-level overview?




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

Re: [Discuss-gnuradio] Why cant I increase signal by 1 hz at a time with high frequencies?

[Michael Ossmann]

On Tue, Sep 08, 2015 at 04:33:38AM +0200, Douglas Beonkey wrote:
>
> If I create a signal source block with a starting frequency of 1.2
> GHz, and in the block have a variable slider added to the frequency
> (assume the variable can slide between 0 and 1000), i must move the
> slider 120 or more steps before the signal shifts on the waterfall
> plot with a gap of 120 or more hz.

Perhaps the frequency is stored as a (32-bit single precision) float.
This data type can store 12.0 and 120128.0 but not the
intermediate integers.

Mike

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

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Marcus Müller]

Hi Dave,
Don't be sorry :)

However, of you've modified the scripts yourself, there's no way for anyone but 
you to find out what goes wrong. Can you save your modifications somewhere 
else, and overwrite all potentially modified scripts with their original 
version?
Ravi has a very similar case, and I recommended not installing over everything 
if Ravi knew where the originals are. If you don't know, reinstalling might be 
the easiest way to get the originals.

Best regards,
Marcus

PS: I'll stop answering emails from Ruby forum now, and wait till you send them 
from your regular email account

Am 8. September 2015 00:13:30 MESZ, schrieb Dave Allen :
>I am sorry. No
>
>-- 
>Posted via http://www.ruby-forum.com/.
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Linking .so files to OOT module

[vamsi krishna]

Hello everyone,
I'm trying to create a source and sink block which will connect to a database 
to fetch and drop data. The interface to the database is created using shared 
libraries (.so files) that were defined by someone else, not us. I have 
included the header file, which contains all the interfaces, inside the include 
folder of the module.
I tried looking for possible solutions and many times it was mentioned to use 
"target_link_libraries" in CMakeLists.txt file. Could anyone let me know how 
and where it should be included?
Note : The code gets compiled and placed into respective folders alright, but 
there is this exception after executing on gnuradio-companion.
Traceback (most recent call last):
File "/xxx/x/.py", line 754, in 
tb = ()
File "/xxx/x/.py", line 617, in __init__
self._src_0 = x._src("127.0.0.1", 1234, "Username", "password")
AttributeError: 'module' object has no attribute '_src'


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

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Marcus Müller]

Hi Dave,

it's monday, and most of us haven't gotten around answering emails from
the weekend, so please accept my apologies for not having exploding
enthusiasm when I saw your first reminder five hours after you posted
your question ;)

So, first of all: thanks for the bug report! It's always good to
eradicate errors.

Which version of GNU Radio are you using (run "gnuradio-config-info
--version")? I think it must be at least from 2013 or older, if these
line numbers are correct, but I could be mistaken. If your GNU Radio is
in fact as old as that, could you try with a newer version, and see
whether that works?

To try locally, we'd need the actual command line that you're executing.

Best regards,
Marcus

PS: One thing: I'm grumpy sometimes, sorry. Also, please sign up with an
email address under
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ; ruby-forum has
lead to numerous problems on this mailing list, because it is an
extraordinarily **bad** mailing list interface, shamelessly using the
mails that we send here.

On 07.09.2015 21:26, Dave Allen wrote:
> Can anyone please give an answer for the above error?
>
> Thanks,
> Dave
>


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

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Mike Jameson]

Hi Dave,

Firstly, please sign up and post to the GNU Radio mailing list via the
official method, not the Ruby forum. GNU Radio has nothing to do with Ruby!

Official GNU Radio mailing list sign-up link:

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

In regard to your question, make sure you specify all parameters on the
command line, especially frequency, lo-offset and antenna to see whether
that fixes it for you.  I believe the 'none-type' error pops up because
some parameter hasn't been specified and the empty parameter isn't error
checked/initialised to '0' correctly if not specified on the command line.
This may be related to the following bug:

https://gnuradio.org/redmine/issues/705

Mike

--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com

On Sun, Sep 6, 2015 at 10:08 PM, Dave Allen  wrote:

> Hi all,
> I have been trying to send data between 2 USRP's from the benchmark_tx
> file only to observe that I have been receiving this error.
>
> Traceback (most recent call last):
>   File "./benchmark_tx.py", line 147, in 
> main()
>   File "./benchmark_tx.py", line 111, in main
> tb = my_top_block(mods[options.modulation], options)
>   File "./benchmark_tx.py", line 49, in __init__
> options.antenna, options.verbose)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 135, in __init__
> freq, gain, antenna)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 62, in __init__
> self._rate, self._sps = self.set_sample_rate(bitrate, sps)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 70, in set_sample_rate
> asked_samp_rate = bitrate * req_sps
> TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'
>
> I am unable to understand what this error means? I have tried to search
> in the Internet about this but found nothing relevant. Please advice as
> to what I can do?
>
> Thanks,
> Dave
>
> --
> Posted via http://www.ruby-forum.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

Re: [Discuss-gnuradio] Throttle block form wav files

[Murray Thomson]

On 3 September 2015 at 17:04, Murray Thomson 
wrote:

>
> On 3 September 2015 at 16:43, Kevin Reid  wrote:
>
>> On Sep 3, 2015, at 8:24, Murray Thomson 
>> wrote:
>>
>> > Even selecting source and sink from the audio card, if I have a wav
>> file playing in another input of the selector without a throttle, the CPU
>> goes to 100%. To avoid it I put the wav file, then the throttle and the the
>> selector. I've read that is bad practice but I couldn't reduce the CPU
>> usage in any other way.
>>
>> (Please make sure to CC the mailing list in your replies.)
>>
>
> Sorry, it was a mistake. For the list, just clarify that
> I have an audio sink using the same audio card @ 96 KHz with the settings
> set to OK to block YES.
>
>
>> Ah. I just looked at the implementation of the selector block, and found
>> that its documentation lies. It does not leave its unused inputs
>> “disconnected” (which is actually good, because that would cause errors in
>> some cases), but connects them to null sinks (which consume all the input
>> they're given).
>>
>> So, using a throttle is a workaround for this. (The cost is that since
>> the throttle's timing is based on the CPU clock, not the audio card clock,
>> you'll occasionally get either underrun or overrun.)
>>
>> Here are some better solutions, from simplest to best:
>>
>> 1. Using some method to force the wav source and audio source to match
>> sample rates. Specifically, you could use a “Multiply by Matrix” block to
>> replace the function of the Selector entirely: give it a matrix value of
>> either ((1, 0),) or ((0, 1),) to select just one input.
>>
>
Can I make a multiply to matrix block have several inputs and one only
output? If not, I was thinking on multiplying one of them by a constant
block zero and then adding both outputs. Would this be a valid workaround?


>
>> 2. Modifying, or creating a replacement for, the selector block which
>> does not connect to a null sink but rather to a block of some sort which
>> never accepts any data and so stops that branch of the flowgraph. (I don't
>> think such a block actually exists, but it could, and there might be
>> something else that acts like it.)
>>
>> 3. Actually remove from the flowgraph whichever of the wav source and
>> audio source are not currently in use. This is the most general, efficient,
>> and straightforward solution, but unfortunately it cannot be built within
>> GNU Radio Companion -- you must write some C++ or Python code. If you don't
>> want to stop using GRC entirely, you could isolate that part by putting the
>> connection changing logic inside a hierarchical block; this would be
>> similar to the selector block itself, but it would be a source, which has
>> the wav and audio sources "built into" it. Alternatively, you could write
>> your main()/top block as a Python program and put the _rest_ of your logic
>> (the demodulator and sink) into a GRC block which is used by the Python
>> program. Either way works.
>>
>> Thanks, I'll try these solutions tomorrow. I assume that they also apply
> to add a constant block into a selector block.
>
>
>> --
>> Kevin Reid  
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Noob question 1

[Marcus D. Leech]

On 09/07/2015 02:19 PM, Henk wrote:

My thoughts Ton,
I just made the FM receiver Marcus advised and as discribed in tutorial 6.
This week I will ask a few questions about the configuration of these 
blocks.

Understanding is the key word for me.

Thanks

Henk

It boils down to having an understanding of DSP, which proceeds from 
having an understand of signal processing in general.


There are several good books, including the works of Richard Lyons, and 
Bill Sethares.


There's also:  www.dsprelated.com  and www.complextoreal.com

Also, if basic RF signal-flow concepts are new to you, the first few 
chapters of the ARRL handbook are quite useful, even if you aren't planning

  to become a ham radio operator.




Op 7-9-2015 om 13:38 schreef Ton Machielsen:
Hooking in on the discussion here. I struggle with something similar. 
I know how to work gnuradio, that’s simple enough. What i want to 
learn more about is how to configure my own SDR using gnuradio. So 
what the various blocks are used for, when to use what block, etc.
I have experience LISTENING to an SDR using various devices, now i 
want to BUILD one myself.
The final objective is to learn how to decode well known signals like 
the various HAM radio protocols like PSK31, etc. I know that all has 
been done before and the easy road is to take an existing flow graph, 
copy it and see that it works. But to understand what is happening is 
a whole different story.


So, without trying to hijack the thread, i am NOT looking for a 
gnuradio manual, i am looking for documentation on how to USE 
gnuradio for signal processing.


Thanks for the advice,

Ton.

On Mon, Sep 7, 2015 at 11:27 AM, Henk > wrote:


Hi Jan
Believe me, I am reading the tutorials, also the youtube lessons
https://www.youtube.com/watch?v=N9SLAnGlGQs

But for me it is easier to understand basics when there is a
basic working layout available. There is so much about GNURADIO
out there that a noob also needs some help with the help. (lol).

I am not a technician, developer or electronic engineer so the
learning curve is steep.

Thanks for your replay and links.

When the RTL works I will post the layout here for others.

Best regards

Henk
www.sterrenwachtleeuwarden.nl 


Op 7-9-2015 om 10:47 schreef Jan Krämer:

Hi Henk,

I suggest you start with the guided GNU Radio Tutorials [1].
They contain the basics to work with GNU Radio.
In Tutorial 6 it is explained how to use a hardware source
(USRP, RTL Dongle) with the audio sink [2]. But I suggest
finishing the other tutorials first if you have no experience
with GNURadio.

Cheers and happy hacking,
Jan

[1]
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
[2]

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

2015-09-07 10:03 GMT+02:00 12henk12 :

Hello all
4 weeks ago did my first steps into Linux Ubuntu.
I am trying to get the RTL-Dongel to work but still not
succeded in that,
Time to ask some help.
There is a image with pre-installed drivers and GNU-Radio
companion,
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
I have downloaded that and put it on a USB stick. Works fine.

In the terminal I enter rtl_sdr -t and the RTL-dongel is
found and it works.
Then I start GNUradio companion, it is version 3.7.7.1. The
RTL is found in
the sources.
But the radio has a blue output and the audio-sink a orange
one. In the
Help-doks it says that this is because of the datatype
but I cant change that anywhere. The dongel properties-block
gives "complex
float 32".

Can you help me getting it to work? Only with a working
system I can go
further learning.

Thanks

Henk
www.sterrenwachtleeuwarden.nl




--
View this message in context:
http://gnuradio.4.n7.nabble.com/Noob-question-1-tp55832.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Dave Allen]

Can anyone please give an answer for the above error?

Thanks,
Dave

-- 
Posted via http://www.ruby-forum.com/.

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