Re: [Discuss-gnuradio] PSK demodulator and Doppler

2014-09-03 Thread Vanush Vaswani 
My solution involved the frequency translating block and a third party
application. As part of the initial channel filter, I set the the "Center
Frequency" attribute to -4+fftshift*rx_shift_factor (assuming my LO
tuned to +40 KHz from the carrier). The satellite tracking program,
PREDICT, provides a Doppler shift calculation assuming a 100 MHz carrier.
rx_shift_factor is the satellite carrier frequency divided by 100 MHz. I
then polled PREDICT, which provides a UDP server interface and then in
Python called set_fftshift method on the flowgraph object generated by
gnuradio-companion. In turn, this would update the taps of the FIR filter
to provide a desired frequency shift.

As for temperature drift, I assumed that with a strong enough signal, the
inbuilt Costas loop would be able to bring the signal back to baseband.

The drawback of this solution is that it's not fully contained within
gnuradio-companion, and like you said, requires the orbital elements to be
known. One solution that uses the PLL block is here:
https://www.cgran.org/wiki/ESTCube-1Receiver




On Wed, Sep 3, 2014 at 4:53 PM, Mike Willis  wrote:

> 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  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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PSK demodulator and Doppler

2014-09-03 Thread Tom Rondeau 
On Wed, Sep 3, 2014 at 5:12 AM, Vanush Vaswani  wrote:

> My solution involved the frequency translating block and a third party
> application. As part of the initial channel filter, I set the the "Center
> Frequency" attribute to -4+fftshift*rx_shift_factor (assuming my LO
> tuned to +40 KHz from the carrier). The satellite tracking program,
> PREDICT, provides a Doppler shift calculation assuming a 100 MHz carrier.
> rx_shift_factor is the satellite carrier frequency divided by 100 MHz. I
> then polled PREDICT, which provides a UDP server interface and then in
> Python called set_fftshift method on the flowgraph object generated by
> gnuradio-companion. In turn, this would update the taps of the FIR filter
> to provide a desired frequency shift.
>
> As for temperature drift, I assumed that with a strong enough signal, the
> inbuilt Costas loop would be able to bring the signal back to baseband.
>
> The drawback of this solution is that it's not fully contained within
> gnuradio-companion, and like you said, requires the orbital elements to be
> known. One solution that uses the PLL block is here:
> https://www.cgran.org/wiki/ESTCube-1Receiver
>
>
It might not be completely contained in GRC, but it's a clever solution.

Another thing to look into is the fll_band_edge block. This will only work,
however, if the signal is pulse-shaped. Specifically with an RRC filter by
design, but we can modify it for other pulse shapes as well. This only does
coarse frequency correction, but it's lock in bandwidth is much wider than
that of the Costas loop block. You'd still want to follow this up with the
Costas loop for fine frequency and phase tracking.

One thing, too, is that this block is fairly expensive computationally.
It's calculating two FIR filters, which should be replaced by fast
convolution filters. And I think that we could even combine this into a
single filter operation.

Tom



> On Wed, Sep 3, 2014 at 4:53 PM, Mike Willis  wrote:
>
>> 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  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 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] AttributeError: 'module' object has no attribute 'block_name'

2014-09-03 Thread Simone Ciccia S210664 
Hi,
I created a C++ block with gr_modtool,
following the commands:

$ gr_modtool newmod PWagc
$ gr_modtool add -t general power_control

I written and compiled my block with commands:

$cmake ../ && make && sudo make install && sudo ldconfig

Until this point all seems ok, but when I open gnuradio and try to simulate
my block...
the following error appears:

Traceback (most recent call last):
  File "/home/simone/Scrivania/top_block.py", line 261, in 
tb = top_block(address=options.address)
  File "/home/simone/Scrivania/top_block.py", line 153, in __init__
self.PWagc_power_control_0 = PWagc.power_control(0.001, 0.25)
AttributeError: 'module' object has no attribute 'power_control'


I'm not able to understand from which this error derive...
If needed, I can attach the _impl.cc etc... files.

My gnuradio version is the 3.7.4 and
PYTHONPATH=/usr/local/lib/python2.7/dist-packages,
in this last folder I can see the installed gr-PWagc directory.

Someone can help me please?
If additional information are needed, please ask me... I'm blocked here!

Thanks,
Simone Ciccia

___
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-03 Thread Tiankun Hu 

Hi Martin,
Thank you, I got it. Those code take charge correcting phase shift 
caused by CP.

The real IFO correcting is done when copy IN buff to OUT buff.
Seems there is a minor issue, if all carriers were occupied by data, OUT 
buff will lose some data, right?


// Copy the frame and the channel state vector
// such that the symbols are shifted to the correct position
if (carrier_offset < 0) {
memset((void *) out, 0x00, sizeof(gr_complex) * 
(-carrier_offset));<===1

memcpy(
(void *) &out[-carrier_offset], (void *) in,
sizeof(gr_complex) * (d_fft_len * frame_len + 
carrier_offset)

  );
} else {
memset((void *) (out + d_fft_len * frame_len - 
carrier_offset), <2

0x00, sizeof(gr_complex) * carrier_offset);
memcpy(
(void *) out, (void *) (in+carrier_offset),
sizeof(gr_complex) * (d_fft_len * frame_len - 
carrier_offset)

  );
}


在 2014年09月02日 23:37, 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;
}
}





--
Thanks
Tiankun



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

Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'block_name'

2014-09-03 Thread Tom Rondeau 
On Wed, Sep 3, 2014 at 9:17 AM, Simone Ciccia S210664 <
simone.cic...@studenti.polito.it> wrote:

> Hi,
> I created a C++ block with gr_modtool,
> following the commands:
>
> $ gr_modtool newmod PWagc
> $ gr_modtool add -t general power_control
>
> I written and compiled my block with commands:
>
> $cmake ../ && make && sudo make install && sudo ldconfig
>
> Until this point all seems ok, but when I open gnuradio and try to simulate
> my block...
> the following error appears:
>
> Traceback (most recent call last):
>   File "/home/simone/Scrivania/top_block.py", line 261, in 
> tb = top_block(address=options.address)
>   File "/home/simone/Scrivania/top_block.py", line 153, in __init__
> self.PWagc_power_control_0 = PWagc.power_control(0.001, 0.25)
> AttributeError: 'module' object has no attribute 'power_control'
>
>
> I'm not able to understand from which this error derive...
> If needed, I can attach the _impl.cc etc... files.
>
> My gnuradio version is the 3.7.4 and
> PYTHONPATH=/usr/local/lib/python2.7/dist-packages,
> in this last folder I can see the installed gr-PWagc directory.
>
> Someone can help me please?
> If additional information are needed, please ask me... I'm blocked here!
>
> Thanks,
> Simone Ciccia
>

We've been seeing this issue from a few people recently. I can't duplicate
the problem. I just did exactly what you did above, though the work
function doesn't actually do anything.

Are you potentially adding some interface setter or getter to the class and
not putting it in all the right places (pure virtual in the public header,
then again in the private header, and implemented in the source file)?

Have you added QA code? In qa_power_control.py, just add a line to the test
function to create the PWagc.power_control(x,y) and see if it works there.

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

Re: [Discuss-gnuradio] root_raised_cosine principle

2014-09-03 Thread Tom Rondeau 
On Mon, Sep 1, 2014 at 11:50 AM, Martin Braun 
wrote:

> Please stick to the list.
>
> On 09/01/2014 05:35 PM, adream wrote:
> > Thanks for your reply
> > May be I should make my question more specifically,
> >
> > den = -32 * M_PI * alpha * alpha * xindx/spb;
> >
> > I can't understand well why there is "-32"
>
> That I don't know. Of course, it's just a gain change, so it won't
> affect the spectral shape.
> Perhaps Tom can weigh in here.
>
> M
>

I looked at that, and I'm not sure where that 32 came from. This code is
very old, probably back from the late 90's even. I probably would have
written that a lot differently than the code that's in there, but I will
say that this code does at least build an RRC filter. Though I'd be curious
if you could point to the results being (significantly) different given
what you think the filter coefficients given the same parameters should be.

Tom



> >
> > thank you
> >
> >
> > 2014-09-01 23:18 GMT+08:00 Martin Braun  > >:
> >
> > On 09/01/2014 05:01 PM, adream wrote:
> > > Hi,
> > >I get the source code of root_raised_cosine function in
> > gr_firdes.cc,
> > > but I can't understand why it writes in that way, is there any
> > paper can
> > > give me more details about the principle of root_raised_cosine
> >
> > Any standard textbook on digital communications will explain this.
> You
> > might want to look out for keywords such as pulse shaping and Nyquist
> > criterion. Have a look at the wiki page for recommended reading.
> >
> > M
> >
> > > Thank you
> > >
> > > this is the source code of root_raised_cosine
> > > vector gr_firdes::root_raised_cosine (double gain,
> > >double sampling_freq,
> > >double symbol_rate,
> > >double alpha,
> > >int ntaps)
> > > {
> > >   ntaps |= 1;// ensure that ntaps is odd
> > >
> > >   double spb = sampling_freq/symbol_rate; // samples per bit/symbol
> > >   vector taps(ntaps);
> > >   double scale = 0;
> > >   for(int i=0;i > > {
> > >   double x1,x2,x3,num,den;
> > >   double xindx = i - ntaps/2;
> > >   x1 = M_PI * xindx/spb;
> > >   x2 = 4 * alpha * xindx / spb;
> > >   x3 = x2*x2 - 1;
> > >   if( fabs(x3) >= 0.01 )  // Avoid Rounding errors...
> > > {
> > >   if( i != ntaps/2 )
> > > num = cos((1+alpha)*x1) +
> > sin((1-alpha)*x1)/(4*alpha*xindx/spb);
> > >   else
> > > num = cos((1+alpha)*x1) + (1-alpha) * M_PI / (4*alpha);
> > >   den = x3 * M_PI;
> > > }
> > >   else
> > > {
> > >   if(alpha==1)
> > > {
> > >   taps[i] = -1;
> > >   continue;
> > > }
> > >   x3 = (1-alpha)*x1;
> > >   x2 = (1+alpha)*x1;
> > >   num = (sin(x2)*(1+alpha)*M_PI
> > >  - cos(x3)*((1-alpha)*M_PI*spb)/(4*alpha*xindx)
> > >  + sin(x3)*spb*spb/(4*alpha*xindx*xindx));
> > >   den = -32 * M_PI * alpha * alpha * xindx/spb;
> > > }
> > >   taps[i] = 4 * alpha * num / den;
> > >   scale += taps[i];
> > > }
> > >
> > >   for(int i=0;i > > taps[i] = taps[i] * gain / scale;
> > >
> > >   return taps;
> > > }
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'block_name'

2014-09-03 Thread Simone Ciccia S210664 
Very thanks for the immediate answer,

Sorry, I forgot that I passed two arguments when the block was created:

$insert valid arguments: float reference, float alpha

while "unsigned int d_counter" is a normal variable initialized in the
constructor. 

now, in the file power_control_impl.h (in short) I added the variables:

class power_control_impl : public power_control
{
 private:
float d_alpha, d_ref;
unsigned int d_counter;


and then, in the constructor of the file power_control_impl.cc (in short) I
used the settler:

power_control_impl::power_control_impl(float alpha, float reference)
  : gr::block("power_control",gr::io_signature::make2(2, 2,
sizeof(float), sizeof(float)),
  gr::io_signature::make(1, 1, sizeof(float))), d_alpha(alpha),
d_ref(reference)
{
 d_counter=0
}


the xml file (in short) I think is ok:

 PWagc.power_control($alpha, $reference)
  
Alpha
alpha
float
  
  
Reference
reference
float
  


is there something in the wrong place?
thanks for the help! 
Simone




On Wed, 3 Sep 2014 09:35:35 -0400, Tom Rondeau  wrote:
> On Wed, Sep 3, 2014 at 9:17 AM, Simone Ciccia S210664 <
> simone.cic...@studenti.polito.it> wrote:
> 
>> Hi,
>> I created a C++ block with gr_modtool,
>> following the commands:
>>
>> $ gr_modtool newmod PWagc
>> $ gr_modtool add -t general power_control
>>
>> I written and compiled my block with commands:
>>
>> $cmake ../ && make && sudo make install && sudo ldconfig
>>
>> Until this point all seems ok, but when I open gnuradio and try to
>> simulate
>> my block...
>> the following error appears:
>>
>> Traceback (most recent call last):
>>   File "/home/simone/Scrivania/top_block.py", line 261, in 
>> tb = top_block(address=options.address)
>>   File "/home/simone/Scrivania/top_block.py", line 153, in __init__
>> self.PWagc_power_control_0 = PWagc.power_control(0.001, 0.25)
>> AttributeError: 'module' object has no attribute 'power_control'
>>
>>
>> I'm not able to understand from which this error derive...
>> If needed, I can attach the _impl.cc etc... files.
>>
>> My gnuradio version is the 3.7.4 and
>> PYTHONPATH=/usr/local/lib/python2.7/dist-packages,
>> in this last folder I can see the installed gr-PWagc directory.
>>
>> Someone can help me please?
>> If additional information are needed, please ask me... I'm blocked here!
>>
>> Thanks,
>> Simone Ciccia
>>
> 
> We've been seeing this issue from a few people recently. I can't
duplicate
> the problem. I just did exactly what you did above, though the work
> function doesn't actually do anything.
> 
> Are you potentially adding some interface setter or getter to the class
and
> not putting it in all the right places (pure virtual in the public
header,
> then again in the private header, and implemented in the source file)?
> 
> Have you added QA code? In qa_power_control.py, just add a line to the
test
> function to create the PWagc.power_control(x,y) and see if it works
there.
> 
> Tom

___
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-03 Thread mleech 
 

Using predict is a similar solution to what I do in simple_ra for
"fringe stopping", except that it's all contained within the same chunk
of 

 Python, using a "helper" function that's tied to a every-5-seconds
polling loop. The helper function calculates the required phase 

 rotation, given a number of input parameters relating to the
observation. 

On 2014-09-03 09:03, Tom Rondeau wrote: 

> It might not be completely contained in GRC, but it's a clever solution. 
> 
> Another thing to look into is the fll_band_edge block. This will only work, 
> however, if the signal is pulse-shaped. Specifically with an RRC filter by 
> design, but we can modify it for other pulse shapes as well. This only does 
> coarse frequency correction, but it's lock in bandwidth is much wider than 
> that of the Costas loop block. You'd still want to follow this up with the 
> Costas loop for fine frequency and phase tracking. 
> 
> One thing, too, is that this block is fairly expensive computationally. It's 
> calculating two FIR filters, which should be replaced by fast convolution 
> filters. And I think that we could even combine this into a single filter 
> operation. 
> 
> Tom 
> 
> On Wed, Sep 3, 2014 at 4:53 PM, Mike Willis  wrote:
> 
> 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  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 [1] 
> 
> 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 [1]

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

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

 

Links:
--
[1] 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] integral frequency shift correcting in ofdm_frame_equalizer_vcvc_impl.cc

2014-09-03 Thread Martin Braun 
Well, if all carriers are carrying data, then the signal parametrization is
bad, so this is not really an issue. That would be like leaving out the CP
and then complaining about ISI.

M
On 3 Sep 2014 15:24, "Tiankun Hu"  wrote:

> Hi Martin,
> Thank you, I got it. Those code take charge correcting phase shift caused
> by CP.
> The real IFO correcting is done when copy IN buff to OUT buff.
> Seems there is a minor issue, if all carriers were occupied by data, OUT
> buff will lose some data, right?
>
> // Copy the frame and the channel state vector
> // such that the symbols are shifted to the correct position
> if (carrier_offset < 0) {
> memset((void *) out, 0x00, sizeof(gr_complex) *
> (-carrier_offset));<===1
> memcpy(
> (void *) &out[-carrier_offset], (void *) in,
> sizeof(gr_complex) * (d_fft_len * frame_len +
> carrier_offset)
>   );
> } else {
> memset((void *) (out + d_fft_len * frame_len -
> carrier_offset), <2
> 0x00, sizeof(gr_complex) * carrier_offset);
> memcpy(
> (void *) out, (void *) (in+carrier_offset),
> sizeof(gr_complex) * (d_fft_len * frame_len -
> carrier_offset)
>   );
> }
>
>
> 在 2014年09月02日 23:37, 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;
>>> }
>>> }
>>>
>>>
>>>
>
> --
> Thanks
> Tiankun
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to create a custom header derived from packet_header_default.h

2014-09-03 Thread Andrew Burger 
I am trying to create a custom header format derived from
packet_header_default.h.
I am also doing this in an out of tree module src structure.

I have successfully got it to compile the c++ code but it now fails
when I try to add the swig lines into the
cmake class. I am new to cmake and unclear on how to fix it.

>From the python code I get the following message

NameError: packet_header_myproject is not define


If someone has an example or a tutorial on this would be great.

>From packet_header_default.h
* This is a default packet header (see header_formatter()) for a description
* on the header format). To create other header, derive packet header creator
* classes from this function.

Thanks
-- 
Andrew

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

Re: [Discuss-gnuradio] How to create a custom header derived from packet_header_default.h

2014-09-03 Thread Bastian Bloessl 

On 09/03/2014 05:21 PM, Andrew Burger wrote:

I am trying to create a custom header format derived from
packet_header_default.h.
I am also doing this in an out of tree module src structure.

I have successfully got it to compile the c++ code but it now fails
when I try to add the swig lines into the
cmake class. I am new to cmake and unclear on how to fix it.

 From the python code I get the following message

NameError: packet_header_myproject is not define


If someone has an example or a tutorial on this would be great.

 From packet_header_default.h
* This is a default packet header (see header_formatter()) for a description
* on the header format). To create other header, derive packet header creator
* classes from this function.


I did this for my 802.11 module. Maybe it helps

https://github.com/bastibl/gr-ieee802-11/blob/master/swig/ieee802_11_swig.i#L25

Best,
Bastian

___
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-03 Thread Iain Young, G7III 

I use predict, the xmlrpc server, and it bit of glue code for twiddling
the FIR filter's offset for my Funcube and NOAA receivers to account
for doppler.

Allows me to have tighter BPFs (well LPF's really), although does mean
I need to remember to update the TLE's from time to time!

Biggest problem I have is Funcube-1's beacon has thermal drift as
she comes out of eclipse that goes the opposite way...Been trying
to use a Freq_Det block to help, but not had the time to experiment
recently


Iain
On 03/09/14 15:30, mle...@ripnet.com wrote:



Using predict is a similar solution to what I do in simple_ra for
"fringe stopping", except that it's all contained within the same chunk
of

  Python, using a "helper" function that's tied to a every-5-seconds
polling loop. The helper function calculates the required phase

  rotation, given a number of input parameters relating to the
observation.

On 2014-09-03 09:03, Tom Rondeau wrote:


It might not be completely contained in GRC, but it's a clever solution.

Another thing to look into is the fll_band_edge block. This will only work, 
however, if the signal is pulse-shaped. Specifically with an RRC filter by 
design, but we can modify it for other pulse shapes as well. This only does 
coarse frequency correction, but it's lock in bandwidth is much wider than that 
of the Costas loop block. You'd still want to follow this up with the Costas 
loop for fine frequency and phase tracking.

One thing, too, is that this block is fairly expensive computationally. It's 
calculating two FIR filters, which should be replaced by fast convolution 
filters. And I think that we could even combine this into a single filter 
operation.

Tom

On Wed, Sep 3, 2014 at 4:53 PM, Mike Willis  wrote:

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  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 [1]

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 [1]


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

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



Links:
--
[1] 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] How to create a custom header derived from packet_header_default.h

2014-09-03 Thread Martin Braun 
Make sure you're publically exporting your symbol (using the
MYPROJECT_API macro).

M

On 09/03/2014 05:21 PM, Andrew Burger wrote:
> I am trying to create a custom header format derived from
> packet_header_default.h.
> I am also doing this in an out of tree module src structure.
> 
> I have successfully got it to compile the c++ code but it now fails
> when I try to add the swig lines into the
> cmake class. I am new to cmake and unclear on how to fix it.
> 
> From the python code I get the following message
> 
> NameError: packet_header_myproject is not define
> 
> 
> If someone has an example or a tutorial on this would be great.
> 
> From packet_header_default.h
> * This is a default packet header (see header_formatter()) for a description
> * on the header format). To create other header, derive packet header creator
> * classes from this function.
> 
> Thanks
> 


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

Re: [Discuss-gnuradio] how to stop a flowgraph

2014-09-03 Thread Mostafa Alizadeh 
In the other words, I want to stop top block but I don't know how? If I
have one source and one sink, I could stop the top block by returning -1
from the source, but I don't know what is the solution here when I have
multiple sources.

best,
Mostafa




On Wed, Sep 3, 2014 at 10:20 AM, Mostafa Alizadeh 
wrote:

> 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
>
>


-- 
***
Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/
***
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] cmake / Could not find a package configuration file provided by "Gnuradio"

2014-09-03 Thread Dimitri 

Hi,

I've recently installed gnuradio (3.7.2.1, through apt-get install) on 
my Ubuntu 14.04.


I'd like now to build gr-baz, but cmake returns the following errors:

~/SDR/gr-baz/build$ cmake ..
-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   system
--   thread
CMake Warning at CMakeLists.txt:132 (find_package):
  By not providing "FindGnuradio.cmake" in CMAKE_MODULE_PATH this 
project has
  asked CMake to find a package configuration file provided by 
"Gnuradio",

  but CMake did not find one.

  Could not find a package configuration file provided by 
"Gnuradio" with any

  of the following names:

GnuradioConfig.cmake
gnuradio-config.cmake

  Add the installation prefix of "Gnuradio" to CMAKE_PREFIX_PATH or set
  "Gnuradio_DIR" to a directory containing one of the above files.  If
  "Gnuradio" provides a separate development package or SDK, be 
sure it has

  been installed.


CMake Error at CMakeLists.txt:135 (message):
  GnuRadio Core required to compile baz


-- Configuring incomplete, errors occurred!

I couldn't find gnuradio's cmake files mentioned above. I get the same 
error while trying to build gr-osmosdr.


Would appreciate any help!

Thanks

Dimitri

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

Re: [Discuss-gnuradio] how to stop a flowgraph

2014-09-03 Thread Martin Braun 
On 09/03/2014 07:15 PM, Mostafa Alizadeh wrote:
> In the other words, I want to stop top block but I don't know how? If I
> have one source and one sink, I could stop the top block by returning -1
> from the source, but I don't know what is the solution here when I have
> multiple sources.

That's fine, your fg will eventually shut down. You can also call stop()
on your top_block.

M

> 
> best, 
> Mostafa 
> 
> 
> 
> 
> On Wed, Sep 3, 2014 at 10:20 AM, Mostafa Alizadeh
> mailto:m.alizade...@gmail.com>> wrote:
> 
> Hi all, 
> 
> I have the following flowgraph: 
> 
> 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
> 
> 
> 
> 
> -- 
> ***
> Department of Electrical Engineering
> Aboureyhan Building
> MMWCL LAB
> Amirkabir University Of Technology
> Tehran
> IRAN
> Tel: +98 (919) 158-7730
> LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
> 
> Homepage: http://ele.aut.ac.ir/~alizadeh/
> 
> ***
> 
> 
> ___
> 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] cmake / Could not find a package configuration file provided by "Gnuradio"

2014-09-03 Thread Michael Dickens 
Hi Dimitri - I'm not sure the GR cmake files are being installed in that 
version of GR.  On Linux by default, these files will be installed into 
"${prefix}/lib/cmake/gnuradio/", and there will be one called 
"GnuradioConfig.cmake".  gr-baz does not provide this specific file, and if the 
specific GR version does not either then it's no wonder CMake is erroring out.  
Is there any way to install a newer version of GR? - MLD

On Sep 3, 2014, at 1:33 PM, Dimitri  wrote:
> I've recently installed gnuradio (3.7.2.1, through apt-get install) on my 
> Ubuntu 14.04.
> 
> I'd like now to build gr-baz, but cmake returns the following errors:
>CMake Warning at CMakeLists.txt:132 (find_package):
>  By not providing "FindGnuradio.cmake" in CMAKE_MODULE_PATH this project 
> has
>  asked CMake to find a package configuration file provided by "Gnuradio",


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

[Discuss-gnuradio] ZedBoard GNU Radio image boot problems

2014-09-03 Thread Nowlan, Sean 
I'm trying to boot a ZedBoard with the GNU Radio image here: 
http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the hard 
float image even though the tutorial points to the soft float image 
(http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don't know why I'd 
want the soft float image since using the FPU will be much faster.

I followed the directions at the aforementioned tutorial except I renamed 
"u-boot.bin" to "BOOT.BIN" and "uImage-zedboard-zynq7.dtb" to "devicetree.dtb". 
I could not get the board to boot. The USB-to-UART triggers cdc_acm to load 
/dev/ttyACM0 on my Linux host PC, but there is no activity over serial. I'm 
confident the board is not dead because I am able to boot from the preloaded SD 
card that came with the ZedBoard development kit. Does anybody have any 
suggestions? It seems like either some step is missing or I am misunderstanding 
a step in the tutorial.

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

Re: [Discuss-gnuradio] ZedBoard GNU Radio image boot problems

2014-09-03 Thread Tom Rondeau 
On Wed, Sep 3, 2014 at 4:30 PM, Nowlan, Sean 
wrote:

>  I’m trying to boot a ZedBoard with the GNU Radio image here:
> http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the
> hard float image even though the tutorial points to the soft float image (
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don’t know
> why I’d want the soft float image since using the FPU will be much faster.
>

There's a bug in ORC on hard float. So we were looking into soft float +
ORC or hard flow - ORC. Now that we've checked in all of Nathan's NEON VOLK
kernels to GNU Radio, we mostly cover all of the cases where we were
benefiting from ORC.

Bottom line, at this point in the development, use hard float. We will
likely stop all support of soft float images in the future.



>  I followed the directions at the aforementioned tutorial except I
> renamed “u-boot.bin” to “BOOT.BIN” and “uImage-zedboard-zynq7.dtb” to
> “devicetree.dtb”. I could not get the board to boot. The USB-to-UART
> triggers cdc_acm to load /dev/ttyACM0 on my Linux host PC, but there is no
> activity over serial. I’m confident the board is not dead because I am able
> to boot from the preloaded SD card that came with the ZedBoard development
> kit. Does anybody have any suggestions? It seems like either some step is
> missing or I am misunderstanding a step in the tutorial.
>
>
>
> Thanks,
>
> Sean Nowlan
>

u-boot.bin != BOOT.BIN. I know it feels like it should, but it's missing
the first stage boot loader (fsbl). There are licensing issues with
distributing that ourselves. I might have the details slightly wrong since
it's been a while. But basically, follow the instructions on the Zynq wiki
you linked to above to build your of fsbl file and properly build your own
boot.bin. Then DON'T LOSE THAT FILE. That'll be pretty much permanent for
your uses. You did the right thing with the device tree file, as that might
be updated and changed and we'll continue providing that.

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

[Discuss-gnuradio] Minor patch to config file placement

2014-09-03 Thread Nick B 
Subject: [PATCH] gnuradio-runtime: config file placement was not consistent

---
 gnuradio-runtime/CMakeLists.txt |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gnuradio-runtime/CMakeLists.txt
b/gnuradio-runtime/CMakeLists.txt
index 1f94242..7660642 100644
--- a/gnuradio-runtime/CMakeLists.txt
+++ b/gnuradio-runtime/CMakeLists.txt
@@ -136,7 +136,7 @@ install(
 if(ENABLE_GR_LOG AND HAVE_LOG4CPP)
 install(FILES
 ${CMAKE_CURRENT_SOURCE_DIR}/gr_log_default.conf
-DESTINATION ${GR_CONF_DIR}/gnuradio
+DESTINATION ${GR_PREFSDIR}
 COMPONENT "runtime_runtime"
 )
 endif(ENABLE_GR_LOG AND HAVE_LOG4CPP)
--
1.7.1


gr_log_default.conf was getting placed in /usr/etc/gnuradio instead of
/etc/gnuradio/conf.d (or wherever, depending on compile directives).
Nick
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ZedBoard GNU Radio image boot problems

2014-09-03 Thread Philip Balister 


On 09/03/2014 04:30 PM, Nowlan, Sean wrote:
> I'm trying to boot a ZedBoard with the GNU Radio image here: 
> http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the hard 
> float image even though the tutorial points to the soft float image 
> (http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don't know why 
> I'd want the soft float image since using the FPU will be much faster.
> 

Hard float isn't that much faster. It referes to the ARM abi used for
function calls. Hard float lets you return floats in NEON registers,
which makes functions that return floats faster. Pretty much everything
else is the same. So, it is a win, but not huge, except for certain cases.

Philip

> I followed the directions at the aforementioned tutorial except I renamed 
> "u-boot.bin" to "BOOT.BIN" and "uImage-zedboard-zynq7.dtb" to 
> "devicetree.dtb". I could not get the board to boot. The USB-to-UART triggers 
> cdc_acm to load /dev/ttyACM0 on my Linux host PC, but there is no activity 
> over serial. I'm confident the board is not dead because I am able to boot 
> from the preloaded SD card that came with the ZedBoard development kit. Does 
> anybody have any suggestions? It seems like either some step is missing or I 
> am misunderstanding a step in the tutorial.
> 
> Thanks,
> Sean Nowlan
> 
> 
> 
> ___
> 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] PSK demodulator and Doppler

2014-09-03 Thread madengr 
Just curious, any estimate on how much temperature drift in PPM you are
getting?

Thanks,
Lou
KD4HSO


Mike Willis wrote
> ...and there is also some
> frequency drift with satellite temperature as it enters or comes out of
> eclipse. 





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/PSK-demodulator-and-Doppler-tp50185p50210.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] cmake / Could not find a package configuration file provided by "Gnuradio"

2014-09-03 Thread Dimitri 

Hi Michael,
Thanks for your answer. I actually tried to build the latest version 
from the git repo, but it stopped at 98% with the following errors:
[ 98%] Building CXX object 
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/atsc/atsc_viterbi_decoder_impl.cc.o

Linking CXX shared library libgnuradio-dtv-3.7.6git.so
/usr/bin/ld: cannot find -lgnuradio-analog
/usr/bin/ld: cannot find -lgnuradio-filter
collect2: error: ld returned 1 exit status
Couldn't find out what I'm missing. I have libgnuradio-digital3.7.2.1 
installed but I don't know if that's the one.


On 03.09.2014 22:25, Michael Dickens wrote:

Hi Dimitri - I'm not sure the GR cmake files are being installed in that version of GR.  On Linux 
by default, these files will be installed into "${prefix}/lib/cmake/gnuradio/", and there 
will be one called "GnuradioConfig.cmake".  gr-baz does not provide this specific file, 
and if the specific GR version does not either then it's no wonder CMake is erroring out.  Is there 
any way to install a newer version of GR? - MLD

On Sep 3, 2014, at 1:33 PM, Dimitri  wrote:

I've recently installed gnuradio (3.7.2.1, through apt-get install) on my 
Ubuntu 14.04.

I'd like now to build gr-baz, but cmake returns the following errors:
CMake Warning at CMakeLists.txt:132 (find_package):
  By not providing "FindGnuradio.cmake" in CMAKE_MODULE_PATH this project 
has
  asked CMake to find a package configuration file provided by "Gnuradio",



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

Re: [Discuss-gnuradio] Cmake Error

2014-09-03 Thread Bastian Bloessl 

On 09/04/2014 04:33 AM, zhangwen wrote:


Thank you Bastian! I have downloaded the latest version and complete the
installation of gr-ieee802.11.

Now I am learning to write my own OOT modules from Gnuradio wiki. Could
you give me some advice?


You should have a look at the GNU Radio wiki
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules


I know little about building a block and Cmake tool. And what is gr-fosphor?
I open the .grc and other grc file in example. There are still some
blocks missing, so I can't run the programs. Addition, I try in both
root and normal authority.


Please have a look at the readme
https://github.com/bastibl/gr-ieee802-11#troubleshooting

Best,
Bastian



I attached the pictures of the missing progect.

Best regrads,
Zhang Wen

 > -原始邮件-
 > 发件人: "Bastian Bloessl" 
 > 发送时间: 2014年9月2日 星期二
 > 收件人: zhangwen , "GnuRadio Receiver" 
 > 抄送:
 > 主题: Re: [Discuss-gnuradio] Cmake Error
 >
 > 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