jmfriedt | 27 Feb 12:25 2015
Picon

R820T frequency tuning issue

As briefly mentioned on the #gnuradio IRC mailing list, I am facing an issue with tuning a R820T
DVB-T dongle at the GPS carrier frequency. I had qualified the various dongles at 1.5 GHz, and had
not considered that the conclusions from this measurement would not apply at 1.57 GHz. This issue
only exists when using a R820T and *not* with a E4000 dongle (which works fine at all mentioned
frequencies, and whose datasets allow for processing GPS signals).

I have completed the following experiment:
* a frequency synthesizer (Rohde & Schwartz SMA100) is set to 1570 MHz, output power of -10 dBm,
lab-made antenna (ie, dangling wire)
* R820T DVB-T located next to the synthesizer
* either running rtl_sdr -f 1570000000 -n 100000 file.bin and plotting the resulting log in GNU/Octave
(f=fopen('file.bin');d=fread(f,inf,'uchar');plot(abs(fftshift(fft(d))))) ...
* or in a simple gnuradio-companion flowgraph a gr-osmosdr source connected to the WX GUI FFT sink,
in both cases sampling at 2048 kHz

In the latter case I cannot get any signal, hinting at an unlocked or misconfigured PLL frequency. In the
former case (using rtl_sdr), I get for example http://jmfriedt.sequanux.org/rtlsdr.png in which the
carrier was shifted by 100 kHz steps below 1.57 GHz when recording each curve.

Unfortunately I don't know how to tackle the issue other than by filing this bug report.
gnuradio and gnuradio-companion are 3.7.3
gr-osmosdr is v0.1.1-1-g37b09bc5 (0.1.2git)

The receiver is R820T+RTL2832U, sampling at 2048 kHz.

Thanks, JM

--

-- 
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France
(Continue reading)

Philip Balister | 27 Feb 00:26 2015

Fwd: Re: GNU Radio on Zynq - trouble getting the user_peripheral kernel module to work

Forgot to include the list.

-------- Forwarded Message --------
Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the
user_peripheral kernel module to work
Date: Thu, 26 Feb 2015 15:25:25 -0800
From: Philip Balister <philip <at> balister.org>
To: Marc Jem <mdbjem <at> gmail.com>

On 02/26/2015 02:52 PM, Marc Jem wrote:
> Hi - I am trying to build for ZC706. After Philips fixes yesterday, I used
> following commands to initialize and fetch oe-repo :
> 
>         git clone git://github.com/balister/oe-gnuradio-manifest.git -b
> dizzy
>         mkdir oe-repo
>         cd oe-repo
>         repo init -u git://github.com/jpendlum/zynq-gnuradio-manifest.git

This should be:

repo init -u git://github.com/balister/oe-gnuradio-manifest.git -b dizzy

>         repo sync
> 
>      repo sync was successfull. When I try to build I got error
>              "ERROR: Layer 'networking-layer' depends on layer
> 'meta-python', but this layer is not enabled in your configuration"
> 
>      so I added met-python in bblayers.conf. This took care of above error,
(Continue reading)

postmaster | 26 Feb 21:08 2015

Wav File Source and Audio Sink

Hi all,

I am little bit puzzled by a simple flowgraph.
I have prepared a wav file using following graph: Signal Source (float, 
sine, 1khz freq, sample rate 8000) -> Throttle ->  Wav File Sink (sample 
rate 8000, 8 bit per sym).

Then i created graph for listening: Wav file source -> Audio Sink 
(sample rate 8000) + FFT Sink.
And then i ran this flowgraph, i faced with following problem: I don't 
hear anything from audio sink.

FFT sink shows me that data is coming, 1 khz peak is present on FFT, but 
i can't hear it.

Could somebody explain this strange behaviour.

Best regards,
Igor
Mostafa Alizadeh | 26 Feb 15:26 2015
Picon

volk atan

Hi everybody, 

I'm using "volk_32fc_s32f_atan2_32f_a" to compute phase of signal. It's important to know: what is the output phase interval of this function? Is it within [-pi/2,pi/2] as an standard atan function?

This shows its importance when we're dealing with quadrature modulations when you need to wrap the phase between [0,2pi] interval instead of [-pi/2,pi/2].

As I see the output of this function, it also has the phase greater than pi/2, so I guess it automatically wrap the phase. I didn't see any hint about this on the comments, so to be sure, I asked this. 

Best, 
Mostafa  
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Martin Braun | 26 Feb 12:12 2015

IRC, Stack Overflow

Everyone,

this is just a quick reminder for those subscribed to the mailing list that we are active in some other media as well.

For quick discussions, but less permanent records, IRC can be useful. I've updated the corresponding wiki page, because some newer members of this community have mentioned that joining can be a bit scary, maybe this helps:
http://gnuradio.org/redmine/projects/gnuradio/wiki/IRC

We've recently tried to add stack overflow as a means of asking and answering questions, as this gets better search engine indexing and it's really useful for typical limited-scope questions. Find Q's tagged 'gnuradio' here:

http://stackoverflow.com/questions/tagged/gnuradio

There hasn't been much traffic here, but most questions have received good answers (owed, to a large part, to our GSoC alumnus and helpful person Marcus M.).

Please stay respectful regardless of the medium.

Have fun,
Martin
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Tomaž Šolc | 26 Feb 10:41 2015
Picon
Picon

M&M clock recovery for async digital signal

Hi

I'm trying to synchronize on the bits in an asynchronous digital signal
using M&M clock recovery block. For instance, roughly 7 samples of +1.
represent a "1" and roughly 7 samples of -1. represent a "0".

I've reduced the problem the following test case: a square (or sine)
wave generator with a period of 14 samples (a continuous series of 7
sample "1"s and "0"s) and a clock recovery block with the initial value
of omega = 7. This is a fair reproduction of what I see on sync headers
in my signal, which are a long series of such 101010s

https://www.tablix.org/~avian/gnuradio/clock_recovery_test2.grc.png

Am I wrong to assume that the clock recovery should in this case return
roughly [+1, -1, +1, -1, ...] (synchronizing on the crests of the input
signal)?

This does not seem to happen, neither for a square wave nor a sine wave.
The clock recovery never seems to settle on the correct frequency and
phase, even when the initial omega matches input frequency perfectly.
I've tried plenty of different settings for mu and omega gains. The sync
just drifts more or less slowly.

https://www.tablix.org/~avian/gnuradio/clock_recovery_test2.grc_scope.png

I see M&M clock recovery is a pretty common source of questions, but I
failed to find a good answer on how to use it. A suggestion I saw is to
write your own synchronizer. I can do that but I don't want to reinvent
the wheel if a well researched one already exists.

Am I misunderstanding what M&M clock recovery is supposed to do? Is
there another existing block that is more suited for this kind of bit
synchronization?

Thanks
Tomaž

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Martin Braun | 26 Feb 08:50 2015

Re: timed dual channel B210 capture gives error "UHD source block got error code 0x2" (ERROR_CODE_LATE_COMMAND)

Hey Martin,

I'm currently out of reach of a B210, but will check this soon.

However, Marcus is right; if you Rx with a single streamer (i.e. a single UHD Source), samples will be aligned.

Cheers,
the other Martin

On Thu, Feb 26, 2015 at 8:46 AM, Martin Braun <martin.braun <at> ettus.com> wrote:
Hey Martin,

I'm currently out of reach of a B210, but will check this soon.

However, Marcus is right; if you Rx with a single streamer (i.e. a single UHD Source), samples will be aligned.

Cheers,
the other Martin

On Mon, Feb 23, 2015 at 11:32 PM, Martin <gnuradiomail <at> olifantasia.com> wrote:


On 22-02-15 22:35, Marcus D. Leech wrote:
On 02/22/2015 04:26 PM, Martin wrote:
Small addition.
I just want to start capturing on both channels of a B210 at the exact
same time. I do not mind which time that is, as long as the samples
are aligned.

I have read a discussion on this mailinglist which made it clear that
you do need to set a start_time (timed_capturing) with dual-channel
capturing with a B210 to have both channels synchronized.
You should not set the internal B210 clock with set_time_now, since
this would set a slightly different time in the two different channels.
This would then result in a random clock misalignment betwen the
channels of up to 250 usec.

it was advised to use set_time_unknown_PPS or leave the time at the
default internal initiated time. This way both channels should have an
aligned internal clock.

Then using a start_time in the near future should result in perfectly
aligned captures. But as I said in my previous mail, this results (for
me) in the UHD error.
"UHD source block got error code 0x2"


Martin

I use a GR flow-graph to do this for interferometry, without having to
specify anything special.

I use a subdev spec of "A:A A:B"  and specify two channels in the source
block.  Everything lines up nicely.  You might look at the code that
   situation generates if you're hand-coding.

Thanks for the tip. I am going to test this.

I read the following thread on the usrp-users list which suggests several (counterintuitive) things you need to do right to get sample-aligned dual-channel capturing on B210:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011360.html

Are you sure that you get sample-aligned samples without using a start-time. The thread mentioned above suggests that you could get up to 250 usec time difference between the channels.

Note that I generated the basis for my flowgraph with GRC and manually added the start_time code.

See my code as attachments at:
http://gnuradio.org/redmine/issues/769

I hope that you are right and that I do not need the start_time code for this application.
But even if I do not need it. I think it should work without errors. For some (other)applications I actually do need timed capturing.

Thanks,

Martin






On 22-02-15 21:53, Martin wrote:
When you start a dual channel timed capture in the near future with a
B210, the work method of usrp_source_impl.cc prints out

"UHD source block got error code 0x2"

error codes are defined in:
metadata.hpp line 99:
//! A stream command was issued in the past.
ERROR_CODE_LATE_COMMAND = 0x2,

No matter what starttime (in the future) was chosen, UHD always thinks a
command is scheduled to be run in the past (too late)

When I do the same with a single-channel script on the same B210
everything works fine without errors.


The dual channel always prints out the error, and the single channel
always seems to work fine.
I have tried different settings for the delay, which sets how long in
the future the capture is set to start.
But 0.1 0.2 1.0 2.0 5.0 seconds all seem to fail.

I also tried with or without using 1 PPS to set the clock time, but that
did not help either.

code snippet:

usrp_source_impl.cc
line 663:
switch(_metadata.error_code) {
...
line 692:
default:
std::cout << boost::format("UHD source block got error code 0x%x")
% _metadata.error_code << std::endl;
return num_samps;


I created an issue on gnuradio.org and attached example python scripts
there to demonstrate the error. Dual channel script fails, single
channel works.
http://gnuradio.org/redmine/issues/769
The defaults are fine for demonstrating the behaviour so you do not need
to give any arguments.
Note that I used a B210 with an embedded GPSDO, which might be
important.

It is also very possible that I am doing something very wrong.
Please let me know.


With best regards,

Martin Dudok van Heel

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

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


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

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


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Martin Braun | 26 Feb 08:51 2015

Re: (no subject)

Hi,

the Costas-Loop makes sure the phase is corrected -- within possible ambiguity -- for the slicer. For QPSK, this means that the constellation points are mapped to the four points (on the corners of a square) as you would expect, but there are 4 possible rotations how to achieve this. Look up "phase synchronisation" for more details.

Have a look at the costas_loop_cc source code, in gr-digital.

M

On Thu, Feb 26, 2015 at 8:42 AM, Martin Braun <martin.braun <at> ettus.com> wrote:
Hi,

the Costas-Loop makes sure the phase is corrected -- within possible ambiguity -- for the slicer. For QPSK, this means that the constellation points are mapped to the four points (on the corners of a square) as you would expect, but there are 4 possible rotations how to achieve this. Look up "phase synchronisation" for more details.

Have a look at the costas_loop_cc source code, in gr-digital.

M

On Thu, Feb 26, 2015 at 8:28 AM, Vishwanatha H G <vishwanatha.1si12ec423 <at> gmail.com> wrote:
sir, what is the importance of the COSTOS loop in the QPSK mod/demod? This block is working fine for 4-qpsk, 8-qpsk. But it does not works for QAM modulation techniques. Is it needs to modify the cc code? if it is, where I have to modify? plz mail me.

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



_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Vishwanatha H G | 26 Feb 08:28 2015
Picon

(no subject)

sir, what is the importance of the COSTOS loop in the QPSK mod/demod? This block is working fine for 4-qpsk, 8-qpsk. But it does not works for QAM modulation techniques. Is it needs to modify the cc code? if it is, where I have to modify? plz mail me.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Tom Rondeau | 25 Feb 21:49 2015

Re: Cmake can't find 'gnuradio-pmt'

On Tue, Feb 24, 2015 at 7:23 PM, ben Gee <grben777 <at> gmail.com> wrote:
Hello All:
      this is my first time on the list. I'm running gnuradio 3.7.6.1 with pybombs. I'm now trying to install OpenLTE which is dependent on Gnuradio and when it calls cmake to check for gnuradio's packages it can't find it. Originally, the 'FindGnuradio.cmake' file wasn't in the cmake/modules directory, so that was an easy fix, now it runs a little further, and this is the output:


-- Boost version: 1.54.0

-- Found the following Boost libraries:

--   system

Checking for GNU Radio Module: RUNTIME

 * INCLUDES=/home/cnlsdr1/pybombs/include

 * LIBS=/home/cnlsdr1/pybombs/lib/libgnuradio-runtime.so

GNURADIO_RUNTIME_FOUND = TRUE

Checking for GNU Radio Module: BLOCKS

 * INCLUDES=/home/cnlsdr1/pybombs/include

 * LIBS=/home/cnlsdr1/pybombs/lib/libgnuradio-blocks.so

GNURADIO_BLOCKS_FOUND = TRUE

Checking for GNU Radio Module: FILTER

 * INCLUDES=/home/cnlsdr1/pybombs/include

 * LIBS=/home/cnlsdr1/pybombs/lib/libgnuradio-filter.so

GNURADIO_FILTER_FOUND = TRUE

Checking for GNU Radio Module: PMT

-- checking for module 'gnuradio-pmt'

--   package 'gnuradio-pmt' not found

 * INCLUDES=GNURADIO_PMT_INCLUDE_DIRS-NOTFOUND

 * LIBS=GNURADIO_PMT_LIBRARIES-NOTFOUND

-- Could NOT find GNURADIO_PMT (missing:  GNURADIO_PMT_LIBRARIES GNURADIO_PMT_INCLUDE_DIRS) 

GNURADIO_PMT_FOUND = FALSE

CMake Error at /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:97 (message):

  Required GNU Radio Component: PMT missing!

Call Stack (most recent call first):

  /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:123 (GR_MODULE)

  CMakeLists.txt:92 (find_package)



-- Configuring incomplete, errors occurred!


I usually just figure this stuff out on my own or with the help of coworkers, but i figured i'd give the group a try.

Any help with this would be greatly appreciated.

Thanks,

-ben


It looks like there's some confusion in the configuration process. It looks like it's using FindGnuradio.cmake, which will be removed in the next API version update since we are now using the GnuradioConfig.cmake method of doing this. This shouldn't be a problem, but It looks like there might be a bug that's causing this because of the install and cmake paths.

Take a look at /usr/share/cmake-2.8/Modules/FindGnuradio.cmake and go to the very last line and make this substitution:

-GR_MODULE(PMT gnuradio-pmt pmt/pmt.h gnuradio-pmt)
+GR_MODULE(PMT gnuradio-runtime pmt/pmt.h gnuradio-pmt)

The PMT library is provided by gnuradio-runtime, so they are in the same package config info.

Tom



_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
vilvaneshk . | 25 Feb 18:21 2015

Hello everyone,
                          I am vilvanesh k,an undergraduate ,studying electronics and communication engineering in IIT BHU,Varanasi,India.I want to join the GNU Radio community and contribute to the same. Few of my college mate's awesome experience as a open source developer and being a part of the open source community in GSoC were my primary source of inspiration.I have written a brief note about myself to give a better understanding.

What I have done till now:
Read the following pages:
1.http://gnuradio.org/redmine/projects/gnuradio/wiki.
2.http://gnuradio.org/redmine/projects/gnuradio/wiki/HowToUse.
3.http://gnuradio.org/redmine/projects/gnuradio/wiki/HowToGetInvolved.
4.http://gnuradio.org/redmine/projects/gnuradio/wiki/Developmdedicatettp://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors.

and more related sub links.

Searched the entire mailing list archive for advice/instructions to beginners.

Installed gnu radio and all the dependencies (from the build script(it was very helpful))and

I have googled what all can I do with gnu radio, just to understand the power of it!

Skills and resources:
C++ - I have been learning it for the past two years and have written programmes in high school.
I have a 24*7access to Asia's largest cyber library(thousands of journals are available,they can help me in conceptual understanding of the subject)
I can dedicate 4-5 hours daily for the next 14 days and may be more after few weeks.
Note:I don't have any experience in developing softwares,but have done high school level programmes in C++.

With the above things under consideration, I kindly request you all, to give suggestions to me on contributing to the project as a developer.

P.S:If I could get used to the community and become familiar with gnu radio development soon enough,I will draft a proposal for GSoC 2015 and I will be ready to dedicate my summer for GSoC 2015   :-)
Eagerly waiting for a response.

Thanking you,
vilvanesh k.
email address: vilvaneshk <at> gmail.com

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

Gmane