[Discuss-gnuradio] red pitaya with GR?

2017-02-23 Thread Ralph A. Schmid, dk5ras
Hi,

Is the red pitaya usable with gnuradio in an easy way, means, sink/source
block, and ready to go, or is this more hassle? Quick google search did not
show me clear results on this answer...

I am searching affordable hardware similar to a B210 (means, small and
portable) and with perfect gr support, but for 0-30 MHz or so.

With best regards

Ralph.


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


Re: [Discuss-gnuradio] weak signal detection in gnuradio / gqrx

2017-02-23 Thread Marcus D. Leech

On 02/23/2017 11:28 PM, Jon Elson wrote:

Hello,

new user of gnuradio.  I'm still running on Ubuntu 12, so I installed 
a virtual Ubuntu 14.04 guest with Virtualbox, as I couldn't get 
gnuradio to compile on the Ubuntu 12 system.  The virtual 14.04 
install seems to run fine.  I have a

nooelec NESDR smart, rtl-sdr.

I also have linrad installed on the Ubuntu 12 host, and it is able to 
bring out weak CW on the 6m band.  (Don't have an upconverter, yet.)  
There seem to be a couple guys on 6m that are sending slow Morse all 
day long, and they generally give QUITE clear audio. The CW is just 
visible on the waterfall.


So, I tried to tune them in with both gnuradio and gqrx.  Both just 
get noise, and I can't see the signal on the waterfall of FFT graph.  
Now, one thing is that linrad is running my rtl at 200 KS/sec, and 
gnuradio and gqrx seem to "like" over 1 MHz better. If I try to select 
200K Sa/sec in gqrx, it doesn't seem to improve things any.  (Changing 
the sample rate in gnuradio requires some tweaking of the decimation, 
so it isn't one-click away.)


Can anybody suggest some settings that help pull out the weaker CW 
signals with gnuradio?


linrad works better at weak signals, but the user interface is awful!  
Another thing is that linrad uses only very little CPU resources, but 
gnuradio loads my i5 CPU completely.  Does that have anything to do 
with the virtual environment (virtualbox) or is it just the difference 
in the software?


Thanks very much,

Jon


Gnu Radio isn't "a radio with a lot of knobs".   It's a specialized 
programming environment for *building radios*.  You can do anything with it.


Just like you could, given a bucket of electronics parts of suitable 
diversity, build just about anything.  But the parts by themselves just
  lie there, lifeless, until you, the programmer (or, you know 
solderer, to stretch a metaphor) breathe life into them.


You should be able to run gqrx at 250ksps, but I don't off the top of my 
head know how you configure that in gqrx, which is an *APPLICATION*

  that was partially built using the Gnu Radio framework.

Your question (to use a proximate metaphor) is like asking how to 
configure Visual Studio, with C#, to provide the functionality within

  Excel.   The answer would be "well, you'd program it to do so".

Gnu Radio is a programming environment, so, it's easy for the naive 
beginner to construct signal flows that are wildly suboptimal.
  Just like it's possible for the beginning C# (or Java, or Python, or 
C++) programmer to write code that, years hence, might not

  seem that wonderful.

I'd suggest spending some time in the "guided tutorials" section on the 
www.gnuradio.org website, and maybe curl up with a book on

  modern digital signal processing.

With Gnu Radio, there IS NO "what settings do I use to make my signal 
come out.".





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


[Discuss-gnuradio] weak signal detection in gnuradio / gqrx

2017-02-23 Thread Jon Elson

Hello,

new user of gnuradio.  I'm still running on Ubuntu 12, so I 
installed a virtual Ubuntu 14.04 guest with Virtualbox, as I 
couldn't get gnuradio to compile on the Ubuntu 12 system.  
The virtual 14.04 install seems to run fine.  I have a

nooelec NESDR smart, rtl-sdr.

I also have linrad installed on the Ubuntu 12 host, and it 
is able to bring out weak CW on the 6m band.  (Don't have an 
upconverter, yet.)  There seem to be a couple guys on 6m 
that are sending slow Morse all day long, and they generally 
give QUITE clear audio.  The CW is just visible on the 
waterfall.


So, I tried to tune them in with both gnuradio and gqrx.  
Both just get noise, and I can't see the signal on the 
waterfall of FFT graph.  Now, one thing is that linrad is 
running my rtl at 200 KS/sec, and gnuradio and gqrx seem to 
"like" over 1 MHz better.  If I try to select 200K Sa/sec in 
gqrx, it doesn't seem to improve things any.  (Changing the 
sample rate in gnuradio requires some tweaking of the 
decimation, so it isn't one-click away.)


Can anybody suggest some settings that help pull out the 
weaker CW signals with gnuradio?


linrad works better at weak signals, but the user interface 
is awful!  Another thing is that linrad uses only very 
little CPU resources, but gnuradio loads my i5 CPU 
completely.  Does that have anything to do with the virtual 
environment (virtualbox) or is it just the difference in the 
software?


Thanks very much,

Jon

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


Re: [Discuss-gnuradio] Changing the USRP transmitter gain after a timeout

2017-02-23 Thread Derek Kozel
Hello,

The command port interface can be used to change the gain value. There is
an example of creating messages for tuning included in gr-uhd.
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/examples/grc/uhd_msg_tune.grc

I've used a function probe to generate coarsely timed "tick" messages to a
custom python block which is correctly formatting the messages before.
Unfortunately I cannot find that GRC file at the moment. The function probe
will run at an approximate interval dependent on your system and GNU
Radio's scheduler. If you don't need exact timing then just use the gain
message and function probe, if you do need exact timing include both time
and gain values in the pmt command message then the gain will be applied at
the specific time based on the radio timestamp. Set the Sync setting to
unknown_pps, which will set the radio timestamp to 0 when the flowgraph
starts, and set the initial timestamp for the command port message to a
second or two in the future to account for the startup time of the
flowgraph.

Regards,
Derek

On Thu, Feb 23, 2017 at 1:36 PM, Qurat-Ul-Ann Akbar <
quratulannakbar2...@u.northwestern.edu> wrote:

> Hi,
>
> I want to alternate the gain of the USRP between two values after a
> certain period of time. For example after 100 ms it should go from A to B
> and after another 100 ms the value should go from B to A and so on.
>
> Is there an easy way of doing this in the GNU Radio companion or would I
> need to start a timer in python and put an IF condition to keep changing
> the value? Can I do this somehow using the probe block?
>
>
>
> ___
> 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] Changing the USRP transmitter gain after a timeout

2017-02-23 Thread Qurat-Ul-Ann Akbar
Hi,

I want to alternate the gain of the USRP between two values after a certain
period of time. For example after 100 ms it should go from A to B and after
another 100 ms the value should go from B to A and so on.

Is there an easy way of doing this in the GNU Radio companion or would I
need to start a timer in python and put an IF condition to keep changing
the value? Can I do this somehow using the probe block?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] GSL_FOUND both TRUE and FALSE

2017-02-23 Thread Michael Wentz
I've seen this issue in Fedora 23/24/25. It will build the first time fine,
but any successive builds complain about finding GSL. What I ended up doing
is commenting out the last two lines in FindGSL.cmake:

#INCLUDE(FindPackageHandleStandardArgs)
#FIND_PACKAGE_HANDLE_STANDARD_ARGS(GSL DEFAULT_MSG GSL_LIBRARIES
GSL_INCLUDE_DIRS GSL_LIBRARY_DIRS)

-Michael



On Wed, Feb 22, 2017 at 11:14 AM, Geof Nieboer 
wrote:

> I would take a look at the FindGSL.cmake script.  I suspect the issue is
> related to the change to run FindPackage twice.  Perhaps the pkgconfig
> detection isn't pulling in the variables the second time so they are being
> set to nulls?
>
> For a quick test, I would try commenting out the "find_package(GSL)" in
> the gr-dtv CMakeLists.txt and see what happens.
>
> Geof
>
> On Wed, Feb 22, 2017 at 10:42 AM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi all,
>>
>> thank you for your input.
>>
>> Some clarifications:
>>
>> I was indeed cmaking the latest version from git
>>
>> "Building for version: v3.7.10.1-237-g81e7af7b / 3.7.11git"
>>
>> and was working from scratch with a clean built.
>>
>> I attach here the whole output of cmake.
>>
>> thanks for the help ,
>> Achilleas
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 21, 2017 at 6:01 PM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Hi all,
>>>
>>> after a long time update from source on a Fedora 23 I came across the
>>> following problem when cmaking:
>>>
>>> -- Configuring gr-fec support...
>>> --   Dependency ENABLE_VOLK = ON
>>> --   Dependency Boost_FOUND = 1
>>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>>> --   Dependency ENABLE_GR_BLOCKS = ON
>>> --   Dependency GSL_FOUND = TRUE <
>>> --   Enabling gr-fec support.
>>> --   Override with -DENABLE_GR_FEC=ON/OFF
>>> -- Checking for module 'fftw3f >= 3.0'
>>> --   Found fftw3f , version 3.3.4
>>> -- Found FFTW3F: /lib64/libfftw3f.so
>>>
>>> but then
>>>
>>> -- Configuring gr-dtv support...
>>> --   Dependency Boost_FOUND = 1
>>> --   Dependency GSL_FOUND = FALSE  <
>>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>>> --   Dependency ENABLE_GR_ANALOG = ON
>>> --   Dependency ENABLE_GR_FILTER = ON
>>> --   Dependency ENABLE_GR_FEC = ON
>>> --   Disabling gr-dtv support.
>>> --   Override with -DENABLE_GR_DTV=ON/OFF
>>> -- Could NOT find GSL (missing:  GSL_INCLUDE_DIRS GSL_LIBRARY_DIRS)
>>> --
>>> -- Configuring gr-atsc support...
>>> --   Dependency Boost_FOUND = 1
>>> --   Dependency GSL_FOUND = FALSE   <
>>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>>> --   Dependency ENABLE_GR_FFT = ON
>>> --   Dependency ENABLE_GR_BLOCKS = ON
>>> --   Dependency ENABLE_GR_FEC = ON
>>> --   Dependency ENABLE_GR_FILTER = ON
>>> --   Dependency ENABLE_GR_ANALOG = ON
>>> --   Disabling gr-atsc support.
>>> --   Override with -DENABLE_GR_ATSC=ON/OFF
>>>
>>> --
>>> -- Configuring gr-wavelet support...
>>> --   Dependency Boost_FOUND = 1
>>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>>> --   Dependency ENABLE_GR_BLOCKS = ON
>>> --   Dependency ENABLE_GR_ANALOG = ON
>>> --   Dependency GSL_FOUND = FALSE  <
>>> --   Disabling gr-wavelet support.
>>> --   Override with -DENABLE_GR_WAVELET=ON/OFF
>>> --
>>>
>>> and so the packages
>>>
>>> --   * gr-dtv
>>> --   * gr-atsc
>>> --   * gr-wavelet
>>>
>>> are not being built.
>>>
>>> BTW: I have gsl and gsl-devel installed (version 1.16-17)
>>>
>>> Can anyone give me a hint as to what may be wrong here?
>>>
>>> thanks
>>> Achilleas
>>>
>>>
>>
>> ___
>> 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