Re: [Discuss-gnuradio] FFSK/MSK Demodulation in Gnuradio

[Michael Ossmann]

On Tue, Dec 01, 2015 at 02:14:59PM +0100, Michael Kramer wrote:
>
> I have the following problem. I've got a signal and I know it's FFSK
> modulated with a bitrate of 2400. I've tried to read some tutorials or
> find other information about FFSK (which is the same as MSK
> apparently), but I found very little.

I've never heard of FFSK, but it looks to me like you have a secondary
frequency modulation.  In other words, you have a frequency modulated
AFSK signal; the data bits are frequency modulated (FSK) onto a carrier
in the audio range, and then that signal is frequency modulated onto an
RF carrier.  It doesn't look like MSK.

Try using a second frequency demodulation in your flowgraph.  One way
would be to insert Hilbert->Quadrature Demod after your second LPF.
Scope the output of the second Quadrature Demod, and you should see a
squarish signal where data zeros are high and data ones are low (or vice
versa).  You should be able to verify the symbol rate by analyzing this
output and then pass it to a clock recovery block.  You'll probably need
an additional step to center the signal around zero before clock
recovery.

Mike

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

[Discuss-gnuradio] Schedule for GNU Radio 3.7.9 release - abi-compliance-checker

[Maitland Bottoms]

Hi,

I played a bit with the abi-compliance-checker which resulted in the attached 
patch.

Alas, it complained a bit on gr-uhd - perhaps unable to figure out uhd from
the Ettus UHD headers and uhd from gnuradio headers. So I punted, and told
abi-compliance-checker to skip include/gnuradio/uhd paths[1].

Someone with well honed C++ skills (or want to hone their skills) might
want to take a look at that.

The attached make-acc-happy patch applies to both master and maint right now.
Might be a nice goal to have GNU Radio 3.7.9 play well with 
abi-compliance-checker.

-Maitland

P.S.
This is one of the patches I add to gnuradio in making the Debian packages:
https://sources.debian.net/src/gnuradio/3.7.8.1-2/debian/patches/
https://sources.debian.net/src/gnuradio/3.7.8.1-2/debian/patches/make-acc-happy/

Also part of making abi-compliance-checker was fixing up the codec2 code:
https://sources.debian.net/src/gnuradio/3.7.8.1-2/debian/patches/codec2-embedding-fixups/

[1]Here's the config for abi-compliance-checker used in Debian packaging:
https://sources.debian.net/src/gnuradio/3.7.8.1-2/debian/gnuradio-dev.acc/

--- a/gnuradio-runtime/include/gnuradio/sys_pri.h
+++ b/gnuradio-runtime/include/gnuradio/sys_pri.h
@@ -23,7 +23,7 @@
 #define INCLUDED_GNURADIO_SYS_PRI_H
 
 #include 
-#include 
+#include 
 
 /*
  * A single place to define real-time priorities used by the system itself
@@ -31,10 +31,10 @@
 namespace gr {
 
   struct GR_RUNTIME_API sys_pri {
-static rt_sched_param python();  // python code
-static rt_sched_param normal();  // normal blocks
-static rt_sched_param gcell_event_handler();
-static rt_sched_param usrp2_backend();   // thread that services the 
ethernet
+static struct GR_RUNTIME_API rt_sched_param python();// 
python code
+static struct GR_RUNTIME_API rt_sched_param normal();// 
normal blocks
+static struct GR_RUNTIME_API rt_sched_param gcell_event_handler();
+static struct GR_RUNTIME_API rt_sched_param usrp2_backend(); // 
thread that services the ethernet
   };
 
 } /* namespace gr */
--- a/gnuradio-runtime/include/gnuradio/py_feval.h
+++ b/gnuradio-runtime/include/gnuradio/py_feval.h
@@ -23,6 +23,7 @@
 #ifndef INCLUDED_GR_PY_FEVAL_H
 #define INCLUDED_GR_PY_FEVAL_H
 
+#include 
 #include 
 #include 
 
>From d3bdf1d6ddac7d4d65a2b9fbc9600027e92f28ad Mon Sep 17 00:00:00 2001
From: "A. Maitland Bottoms" 
Date: Wed, 11 Nov 2015 10:50:22 -0500
Subject: [PATCH] codec2-embedding-fixup

---
 gr-vocoder/gnuradio-vocoder.pc.in  |  2 +-
 gr-vocoder/include/gnuradio/vocoder/codec2.h   |  2 +-
 gr-vocoder/lib/CMakeLists.txt  |  7 +++
 gr-vocoder/swig/CMakeLists.txt |  1 +
 4 files changed

diff --git a/gr-vocoder/gnuradio-vocoder.pc.in 
b/gr-vocoder/gnuradio-vocoder.pc.in
index c5c860d..f937319 100644
--- a/gr-vocoder/gnuradio-vocoder.pc.in
+++ b/gr-vocoder/gnuradio-vocoder.pc.in
@@ -8,4 +8,4 @@ Description: GNU Radio blocks implementing voice codecs
 Requires: gnuradio-runtime
 Version: @LIBVER@
 Libs: -L${libdir} -lgnuradio-vocoder
-Cflags: -I${includedir}
+Cflags: -I${includedir} @EMBEDDED_CODEC2_INCLUDE@
diff --git a/gr-vocoder/include/gnuradio/vocoder/codec2.h 
b/gr-vocoder/include/gnuradio/vocoder/codec2.h
index a3c2225..871903f 100644
--- a/gr-vocoder/include/gnuradio/vocoder/codec2.h
+++ b/gr-vocoder/include/gnuradio/vocoder/codec2.h
@@ -26,7 +26,7 @@
 #include 
 
 extern "C" {
-#include "../lib/codec2/codec2.h"
+#include 
 }
 
 namespace gr {
diff --git a/gr-vocoder/lib/CMakeLists.txt b/gr-vocoder/lib/CMakeLists.txt
index a347cbf..7e813de 100644
--- a/gr-vocoder/lib/CMakeLists.txt
+++ b/gr-vocoder/lib/CMakeLists.txt
@@ -140,6 +140,9 @@ else (NOT DEFINED GR_USE_SYSTEM_LIBCODEC2)
  else (GR_USE_SYSTEM_LIBCODEC2)
 set(GR_USE_LOCAL_LIBCODEC2 TRUE)
 message(STATUS "Using gnuradio local copy of libcodec2.")
+include_directories(${CMAKE_CURRENT_SOURCE_DIR})
+set(EMBEDDED_CODEC2_INCLUDE "-I\${includedir}/gnuradio/vocoder" 
PARENT_SCOPE)
+set(EMBEDDED_CODEC2_INCLUDE_DIRS ${CMAKE_SOURCE_DIR}/gr-vocoder/lib 
PARENT_SCOPE)
  endif (GR_USE_SYSTEM_LIBCODEC2)
 endif (NOT DEFINED GR_USE_SYSTEM_LIBCODEC2)
 
@@ -151,6 +154,7 @@ mark_as_advanced(LIBCODEC2_INCLUDE_DIR LIBCODEC2_LIBRARIES)
 
 include_directories(
 ${GR_VOCODER_INCLUDE_DIRS}
+${EMBEDDED_CODEC2_INCLUDE_DIRS}
 ${GNURADIO_RUNTIME_INCLUDE_DIRS}
 ${LOG4CXX_INCLUDE_DIRS}
 ${Boost_INCLUDE_DIRS}
@@ -210,6 +214,9 @@ GR_INCLUDE_SUBDIRECTORY(g7xx)
 
 if(GR_USE_LOCAL_LIBCODEC2)
  GR_INCLUDE_SUBDIRECTORY(codec2)
+ install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/codec2/codec2.h
+   DESTINATION ${GR_INCLUDE_DIR}/gnuradio/vocoder/codec2/
+   COMPONENT "vocoder_devel")
 endif(GR_USE_LOCAL_LIBCODEC2)
 
 if(GR_USE_LOCAL_LIBGSM)
diff --git a/gr-vocoder/swig/CMakeLists.txt 

Re: [Discuss-gnuradio] HELP!!! USRPN210+GNURADIO

[Harold Daniel Moreno Urbina]

Like one year ago I was testing with USRP N210 with the blocks attached to
this message.
Note that one is for transmission and the other one for reception. I am
lucky and I got 2 USRP N210, so I was able to send a tone (one sin function
or the add of two sin functions) and receive it correctly.

If you only have one USRP I think you can still try to "see" the wi-fi
spectrum, just investigate the actual subbands of the wifi, I do not know
them exactly, but you can find them easily, then put the "param_freq" in
one of those frequency, check the "peak hold" in the FFT Sink and with luck
and patience a "burst" in the chosen frequency will appear.

Hope it helped.

2015-12-01 4:39 GMT-06:00 mohamid92 :

> Hello everybody
>
> I just start working on USRP with Gnu radio. In last two weeks I was
> looking for tutorial to test my USRP without programming any blocks. The
> only tutorial I found is an FM receiver, but unfortunately frequency range
> of USRPN210 is way much bigger than FM frequencies (400MHZ-to GHZ).
>
>
>
> I am asking if there is any resources that can I use to make familier with
> dealing with USRPN210 and gnuradio, like spectrum analyzer “I searched a
> lot but couldn’t found”.
>
>
>
> I just need anything to observe the input of the USRPN210 , like detecting
> WI-FI signal or anything….
>
>
>
> Thank you in advance and sorry for poor English.
>
>
>
> --
> View this message in context: HELP!!! USRPN210+GNURADIO
> 
> 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
>
>


DialTone_USRP.grc
Description: Binary data


DialTone_usrp_rx.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] uhd_sink samp rate(sps)

[Ekko]

hello
when i set the uhd_sink or uhd_source samp rate to 10M
i got that
The hardware does not support the requested TX sample rate:
Target sample rate:10.00 MSps
Actual sample rate: 8.00 MSps
then i set it to other value,some of them is ok,some not,
i know that the max samp rate of e310 is not 8M
so i want to know what value is ok for the uhd_sink or uhd_source
between the min to max samp rate.

i do not find it on manual page,but i got this message.

thank you

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

Re: [Discuss-gnuradio] uhd_sink samp rate(sps)

[James Humphries]

Hi Ekko,

The sample rate has to be some fraction of the clock rate divided by an
integer. The clock rate on the E310 defaults to 32MHz I believe, so 32MHz
divided by 4 gives you 8 Msps. The system will get you as close as it can
to the desired sample rate. You can set the clock rate to something else to
achieve the 10 Msps rate that you want (try setting it to 30MHz).

-Trip

On Tue, Dec 1, 2015 at 10:17 AM, Ekko  wrote:

> hello
> when i set the uhd_sink or uhd_source samp rate to 10M
> i got that
> The hardware does not support the requested TX sample rate:
> Target sample rate:10.00 MSps
> Actual sample rate: 8.00 MSps
> then i set it to other value,some of them is ok,some not,
> i know that the max samp rate of e310 is not 8M
> so i want to know what value is ok for the uhd_sink or uhd_source
> between the min to max samp rate.
>
> i do not find it on manual page,but i got this message.
>
> thank you
>
> --Ekko
>
> ___
> 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] TETRA demodulator advices

[Tom Rondeau]

On Fri, Nov 27, 2015 at 11:54 AM, Timothée COCAULT <
timothee.coca...@gmail.com> wrote:

> Hi,
>
> I am writing a TETRA demodulator with GNU Radio Companion without any OOT
> block.
>
> My flowgraph works but as I don't have a signal processing background, I'm
> not really sure that my choice of the blocks and their parameters is the
> best for my purpose.
>
> The TETRA modulation uses PI/4 DQPSK with a bitrate of 36 kHz (symbol rate
> of 18 kHz), and a RRC filter.
>
> For now, my decoder consists of :
>
> * Freq Xlating FIR Filter : to center and low-pass the signal, and lower
> the sample rate to have about 2 SPS.
> * Fractional resampler : to have exactly 2 SPS
> * Feed Forward AGC : to normalize the amplitude to 1
> * FLL Band Edge : to fine-tune the frequency
> * Polyphase Clock Sync : to sample the symbols at the right timing
> * Differential Phasor : to get the difference between two symbols
> * Constellation decoder : to discretize the symbols
> * Unpack K bits : to convert the symbols to bits.
>
> The flowgraph and screenshots can be found at
> https://github.com/Tim---/tetra-toolkit/tree/master/grc .
>
> Do you have any advice on how to improve this flowchart ?
>


Timothee,
This is a very open-ended question. It'd take a lot of work for someone to
go through your receiver and make any suggestions. Your best bet is to ask
very pointed questions about a behavior or block.



> Bonus questions :
>
> * using the FLL band edge after the low-pass seems odd because, even if it
> can recover frequency offset, some of the bandwidth will be lost.
> Should I use the error ouput of the FLL to change the freq used by the
> Freq XLating FIR FIlter ? If yes, is there an example of this somewhere ?
>


That's more like it! This is a question we can actually answer.

Yes, you have the issue that you described. You could think to make a block
that could pass a message the frequency translating filter that would
adjust its center frequency, but you won't be able to do that very quickly.
It would be a slow, very coarse frequency correction.

Instead, I would try to figure out the expected maximum frequency offset
and make the LPF of the frequency translating filter block large enough to
accommodate that. This LPF is a channel filter meant to reduce noise power
from adjacent channels, so there is always a tradeoff between that and
being able to lock on to your signal. The clock sync block performs the
actual matched filtering, though, so you're not using this LPF to just
isolate the signal exactly.



> * at first I wanted to use the Constellation receiver, but from what I
> understand the constellations in gnuradio work by first discretizing the
> signal, then doing the diff.
> This does not work with PI/4 DQPSK because you need to first diff the
> complex samples, then discretize.
> Is there any way I could cheat to create a PI/4 DQPSK constellation in
> gnuradio ?
>

I could see overloading the constellation object to have a child class with
memory to handle this case.


> Thanks in advance,
>
> Timothée.
>


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

Re: [Discuss-gnuradio] Asynchronous source with zeros in between

[Tom Rondeau]

On Mon, Nov 30, 2015 at 2:37 PM, Francisco Albani <
francisco.alb...@gmail.com> wrote:

> Hi to all.
>
> (this email subject may be inaccurate)
>
> I need a block with the following characteristics:
>
> * Input port for messages.
> * Output port for complex/float/byte/etc. stream.
> * Forecast always answers 0.
> * Work function first check the message queue. If there are no messages,
> emits zeros; if there are, it emits the samples inside the message.
>


The work function should never directly interact with the message queue. I
think there is one block that does it, but it's a hassle for a couple of
reasons.

The message handler function should receive the message and indicate to the
work function to send it the next time it is called.


> I'm willing to write it, but first I want to hear from the people in the
> list in case this can be crafted using existing blocks or if this idea is
> deemed to fail for some reason I can't see.
>
> I need this in order to transmit N parallel burst radios using something
> like Polyphase Channel Synthesizer. The problem emerges when not all the
> transmitters have data to send and stop the other transmitters flows.
>
> Many thanks!
>
> Bye.
>

Off the top of my head today, I can't think of something existing that does
this, so you're likely to have to implement it yourself.

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

[Discuss-gnuradio] HELP!!! USRPN210+GNURADIO

[mohamid92]

Hello everybody

I just start working on USRP with Gnu radio. In last two weeks I was looking
for tutorial to test my USRP without programming any blocks. The only
tutorial I found is an FM receiver, but unfortunately frequency range of
USRPN210 is way much bigger than FM frequencies (400MHZ-to GHZ).

 

I am asking if there is any resources that can I use to make familier with
dealing with USRPN210 and gnuradio, like spectrum analyzer "I searched a lot
but couldn't found".

 

I just need anything to observe the input of the USRPN210 , like detecting
WI-FI signal or anything..

 

Thank you in advance and sorry for poor English. 

 





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/HELP-USRPN210-GNURADIO-tp57143.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] RFNoc and data rates

[Nicolas Cuervo Benavides]

Hi Sylvain,

Sorry for reviving a relatively old issue. I see that you mentioned some
tweaking to be done on the fft block when the signal are weak. I'm
currently working on an application using this RFNoc blocks and I'm having
that problem: I'm calculating the power received at my radio and below some
power level all my samples are mapped to zero. I'm migrating this power
calculation from a previous GNURadio host implementation, and so far I
haven't been able to determine where is that tweaking to be done. Needless
to say that I'm new in the RFNoC part of SDR.

Would it be possible to elaborate a little bit more on the matter?

Thank you in advance!

Regards,

Nico

On Wed, Sep 23, 2015 at 10:10 AM, Sylvain Munaut <246...@gmail.com> wrote:

> Hi,
>
> >> My question is, is this possible using current RFnoc blocks?, with for
> >> example an average block?
>
> One thing worth considering is the internal precision.
>
> I'm not familiar with the requirement for RA but I assume if you do a
> lot of averaging it's to get rid of the noise and dig out very weak
> signals.
> The current average block might not have enough internal precision for
> your needs and might need to be tweaked a bit.
>
>
> >> Also wondering if a 8k channel FFT block might be expected in RFNoc
> >> anytime soon?
>
> Most of the blocks currently assume that 1 vector / fft size = 1
> packet. And packets have to fit within the MTU, so with 4 bytes per
> sc16 sample, that's 2048 which is the current limit. And I think even
> the internal RFNoC fifos are sized with this MTU size in mind.
>
> So for larger FFTs you'll need other mechanism to synchonize the FFT
> boundaries, like the EOB flag.
>
> Cheers,
>
>   Sylvain
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Nicolás Cuervo Benavides
Handy: +49 157 70476855
Electric and Electronic Engineering department.
Electronic Engineering
Universidad Nacional de Colombia
--
Student M.Sc. Information and Communication Technology
Karlsruher Institut für Technologie
Karlsruhe, Baden Würtemberg, Germany
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Time Raster in OSX 10.10.4 Not Rastering

[Tom Rondeau]

On Wed, Nov 25, 2015 at 1:05 PM, Paul Garver  wrote:

> Tom,
>
> Thanks for the info. I could see a reimplementation as a good project for
> some CS undergrads here at GT. Is there a particular way the QT time raster
> should be rewritten (e.g. using particular libraries, QT versions, etc) to
> be OS X compatible and align with the future direction of QT plots in GR?
> Or is the issue more complicated than just a port/reimplementation? I
> personally find the raster extremely useful for analysis.
>
> PWG
>


Hi Paul,

If there's any work to be done here, we'd want to keep it just in the QT
and QWT family so we don't add on any more dependencies for this. If the
raster plot can be fixed under QWT5, then great, we should do that.
However, we're trying to move on to support QWT6 only, which will be true
for GR 3.8. For OS X, the main impediment is the gr_filter_design tool,
which uses PyQWT that forces the use of QWT5. I have an 80% solution to
fixing this by adding other support to the filter design tool for QT 4 and
QT 5:

https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui

There needs to be some work on the look and feel of the new backends,
though, such as manipulation of the pole-zero plot. If we can get this
finished, we can probably drop PyQWT from the macports installation and
update the dependency there to QWT6.

Tom




> On Nov 25, 2015, at 9:16 AM, Tom Rondeau  wrote:
>
> On Wed, Nov 25, 2015 at 10:08 AM, Paul Garver  wrote:
>
>> The QT Time Raster GUI doesn’t appear to function in the latest
>> gnuradio-devel macports. The plot appears all a single color although the
>> bits into the graph are not constant. I run the same flow graph on my
>> Ubuntu setup and I get the rastered bits plotted as expected. I’m using:
>>
>>  gnuradio-devel
>> @2015_0+docs+grc+jack+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui
>> OSX 10.10.4
>>
>> Simple example: Raster some bits with the gr_time_raster_b
>>  gr_time_raster_b bits.b8
>>
>> Output:
>> Using Volk machine: avx_64_mmx_orc
>> Warning: QWT5 has been found which has serious performance issues with
>> raster plots.
>>  Consider updating to QWT version 6 to use the time raster GUIs.
>>
>> The problem with this warning is that it appears it is nontrivial to use
>> QWT6 with OSX on the current gnuradio builds.
>>
>> Does anyone else have this problem? Does it work in the gnuradio
>> (non-devel) port?
>>
>> PWG
>>
>
> Paul,
>
> Yes, we understand the problem with OS X and QWT5 here. The main problem
> is the PyQWT issue, which we've gotten out of the way for the most part,
> but there are still some problems that Dickens has faced with moving away
> completely. The thought was to give up the raster in favor of the other
> things it enables.
>
> It's also quite possible that the QWT5 problem with the raster plotting is
> simply due to bad coding on my part.
>
> Tom
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio