Re: [Discuss-gnuradio] Cmake Error

2014-09-02 Thread Bastian Bloessl 

On 09/02/2014 08:52 AM, zhangwen wrote:

CMake Warning at CMakeLists.txt:85 (find_package):
   By not providing "FindCppUnit.cmake" in CMAKE_MODULE_PATH this
project has
   asked CMake to find a package configuration file provided by
"CppUnit", but
   CMake did not find one.



Oooops, looks like I delete a bit too much files from cmake/Modules. I 
just restored them. Can you please try again?


But, actually that's a good opportunity to ask what an OOT module has to 
install. Actually, I thought FindCppUnit.cmake is installed with GNU Radio


https://github.com/gnuradio/gnuradio/blob/master/CMakeLists.txt#L391

So maybe it is just a matter of adapting ${CMAKE_MODULE_PATH}?

For now I just did it as gr-fosphor :-)

Best,
Bastian

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

Re: [Discuss-gnuradio] Cmake Error

2014-09-02 Thread Tom Rondeau 
On Tue, Sep 2, 2014 at 3:46 AM, Bastian Bloessl 
wrote:

> On 09/02/2014 08:52 AM, zhangwen wrote:
>
>> CMake Warning at CMakeLists.txt:85 (find_package):
>>By not providing "FindCppUnit.cmake" in CMAKE_MODULE_PATH this
>> project has
>>asked CMake to find a package configuration file provided by
>> "CppUnit", but
>>CMake did not find one.
>>
>
>
> Oooops, looks like I delete a bit too much files from cmake/Modules. I
> just restored them. Can you please try again?
>
> But, actually that's a good opportunity to ask what an OOT module has to
> install. Actually, I thought FindCppUnit.cmake is installed with GNU Radio
>
> https://github.com/gnuradio/gnuradio/blob/master/CMakeLists.txt#L391
>
> So maybe it is just a matter of adapting ${CMAKE_MODULE_PATH}?
>
> For now I just did it as gr-fosphor :-)
>
> Best,
> Bastian
>

Yes, GNU Radio installs FindCppUnit.cmake, so you're probably right about
just having to tell cmake the right place to look for this. Cmake can be
funny about that stuff. Instead, that's why when you build a project with
gr_modtool it puts all of the cmake files into the project for you. Just to
be sure you can always reach them in your project.

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

[Discuss-gnuradio] integral frequency shift correcting in ofdm_frame_equalizer_vcvc_impl.cc

2014-09-02 Thread Tiankun Hu 

Hi All,
I found "ofdm_frame_equalizer_vcvc_impl.cc" use below code to correct 
integral freq shift(IFO) in freq domain, but as I known, the IFO only 
cause signal cyclic shifting in freq domain, why this block use gr_expj 
to correcting IFO in freq domain? might be blow code should be done in 
time domain.


   // Correct the frequency shift on the symbols
   gr_complex phase_correction;
   for (int i = 0; i < frame_len; i++) {
   phase_correction = gr_expj(-M_TWOPI * carrier_offset * d_cp_len 
/ d_fft_len * (i+1));

   for (int k = 0; k < d_fft_len; k++) {
   out[i*d_fft_len+k] *= phase_correction;
   }
   }


--
Thanks
Tiankun



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

Re: [Discuss-gnuradio] integral frequency shift correcting in ofdm_frame_equalizer_vcvc_impl.cc

2014-09-02 Thread Martin Braun 
Tiankan,

this corrects the coarse freq offset propagation due to the CP.
As 'i' increments, this represents later times. So, in a sense, this is
in time direction.

M

On 09/02/2014 04:14 PM, Tiankun Hu wrote:
> Hi All,
> I found "ofdm_frame_equalizer_vcvc_impl.cc" use below code to correct
> integral freq shift(IFO) in freq domain, but as I known, the IFO only
> cause signal cyclic shifting in freq domain, why this block use gr_expj
> to correcting IFO in freq domain? might be blow code should be done in
> time domain.
> 
>// Correct the frequency shift on the symbols
>gr_complex phase_correction;
>for (int i = 0; i < frame_len; i++) {
>phase_correction = gr_expj(-M_TWOPI * carrier_offset * d_cp_len /
> d_fft_len * (i+1));
>for (int k = 0; k < d_fft_len; k++) {
>out[i*d_fft_len+k] *= phase_correction;
>}
>}
> 
> 


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

Re: [Discuss-gnuradio] Cmake Error

2014-09-02 Thread Michael Dickens 
The best way to use the .cmake files installed by GNU Radio in an OOT module is 
to do the
{{{
find_package(Gnuradio [...])
}}}
as close to first thing as possible.  Once that's done, then all of the other 
GR .cmake modules (including FindCppUnit.cmake) will become available when 
using CMake >= 2.8.X.  See:
< 
https://github.com/gnuradio/gnuradio/blob/master/cmake/Modules/GnuradioConfig.cmake#L28
 >
Please note that on CMake 2.6.X and prior this will like -not- work because 
CMAKE_CURRENT_LIST_DIR is not yet supported (at least in my testing on OSX; I 
assume it's the same on other OSs).

Thus, for example, if I change the file gr-ieee802-11/CMakeLists.txt to include 
the following instead of the line setting the CMAKE_MODULE_PATH, then CMake 
2.8+ finds everything as hoped/expected.
{{{

# Find gnuradio build dependencies

set(GR_REQUIRED_COMPONENTS RUNTIME FILTER FFT PMT DIGITAL)
find_package(Gnuradio)
if(NOT GNURADIO_RUNTIME_FOUND)
message(FATAL_ERROR "GnuRadio Runtime required to compile ieee802-11")
endif()
}}}
On CMake 2.6 I need to set the CMAKE_MODULE_PATH to include the directory in 
which GnuradioConfig.cmake is found to get this to work.  I've tried a bunch of 
alternatives to working around this on CMake 2.6, and there's no obvious way to 
do it using just CMake internals / commands.  The best way I can find to do 
this is to create a GnuradioConfig.cmake.in file that internally sets this 
variable correctly (as is done for GnuradioConfigVersion.cmake.in for the 
version info).

I, for one, believe that not having to include all of the already-installed GR 
.cmake files is the way to go if at all possible; it eliminates the need to 
keep updating these files in the various OOT modules as well as reduces file 
redundancy.

Hope this helps! - MLD

On Sep 2, 2014, at 3:46 AM, Bastian Bloessl  wrote:
> Oooops, looks like I delete a bit too much files from cmake/Modules. I just 
> restored them. Can you please try again?
> 
> But, actually that's a good opportunity to ask what an OOT module has to 
> install. Actually, I thought FindCppUnit.cmake is installed with GNU Radio
> 
> https://github.com/gnuradio/gnuradio/blob/master/CMakeLists.txt#L391
> 
> So maybe it is just a matter of adapting ${CMAKE_MODULE_PATH}?
> 
> For now I just did it as gr-fosphor :-)


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

[Discuss-gnuradio] PSK demodulator and Doppler

2014-09-02 Thread Mike Willis 
I am trying to develop a satellite ground station using the PSK demodulator
block. This works fine when tuned accurately. However, with low satellites
there is quite a bit of Doppler at VHF / UHF and there is also some
frequency drift with satellite temperature as it enters or comes out of
eclipse. This is a problem as the signals are relatively narrow in bandwidth
compared to the Doppler and drift. I am wondering how to track this Doppler
in Gnuradio. I have tried a PLL block and while this works it isn't quite
right unless the signal is very strong. It can also get fooled by one of the
many spurious signals encountered on the bands.

 

To some extent the Doppler can be predicted and compensated for, but only
when the orbital parameters are known accurately. Even a few seconds error
at TCA can make quite a difference.

 

Has anyone solved this one?

 

Mike

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

Re: [Discuss-gnuradio] PSK demodulator and Doppler

2014-09-02 Thread Colby Boyer 
On Tue, Sep 2, 2014 at 10:09 AM, Mike Willis  wrote:

> I am trying to develop a satellite ground station using the PSK
> demodulator block. This works fine when tuned accurately. However, with low
> satellites there is quite a bit of Doppler at VHF / UHF and there is also
> some frequency drift with satellite temperature as it enters or comes out
> of eclipse. This is a problem as the signals are relatively narrow in
> bandwidth compared to the Doppler and drift. I am wondering how to track
> this Doppler in Gnuradio. I have tried a PLL block and while this works it
> isn’t quite right unless the signal is very strong. It can also get fooled
> by one of the many spurious signals encountered on the bands.
>
>
>
> To some extent the Doppler can be predicted and compensated for, but only
> when the orbital parameters are known accurately. Even a few seconds error
> at TCA can make quite a difference.
>
>
>
> Has anyone solved this one?
>
>
>
> Mike
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
Is there a preamble/training sequence you can search for? If so, you can
use that to get the initial frequency offset estimate to correct and then
use the PLL to track the fine phase correction.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] how to stop a flowgraph

2014-09-02 Thread Mostafa Alizadeh 
Hi all,

I have the following flowgraph:

[image: Inline image 2]

I want to interrupt the whole flowgraph to back to the main function (C++).
I used to return -1 or WORK_DONE in the work function of the sink block but
it doesn't work. What is the solution?

Thanks in advance,
Mostafa
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PSK demodulator and Doppler

2014-09-02 Thread Mike Willis 
Hi Colin,

 

Not really, though there is an AX25 style header. Far from ideal 0110 flags.

 

Mike

 

From: Colby Boyer [mailto:colby.bo...@gmail.com] 
Sent: 03 September 2014 03:11
To: Mike Willis
Cc: GNU Radio Discussion
Subject: Re: [Discuss-gnuradio] PSK demodulator and Doppler

 

On Tue, Sep 2, 2014 at 10:09 AM, Mike Willis mailto:willis...@gmail.com> > wrote:

I am trying to develop a satellite ground station using the PSK demodulator 
block. This works fine when tuned accurately. However, with low satellites 
there is quite a bit of Doppler at VHF / UHF and there is also some frequency 
drift with satellite temperature as it enters or comes out of eclipse. This is 
a problem as the signals are relatively narrow in bandwidth compared to the 
Doppler and drift. I am wondering how to track this Doppler in Gnuradio. I have 
tried a PLL block and while this works it isn’t quite right unless the signal 
is very strong. It can also get fooled by one of the many spurious signals 
encountered on the bands.

 

To some extent the Doppler can be predicted and compensated for, but only when 
the orbital parameters are known accurately. Even a few seconds error at TCA 
can make quite a difference.

 

Has anyone solved this one?

 

Mike


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

 

Is there a preamble/training sequence you can search for? If so, you can use 
that to get the initial frequency offset estimate to correct and then use the 
PLL to track the fine phase correction. 

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