Re: [Discuss-gnuradio] Unable to stop the flow graph after calling stop()

2014-03-03 Thread Marcus Müller 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Activecat,

the constructor of a block must have been called before the block has
been connect()ed; so there's no way a flowgraph is already running
when your block's constructor is called.

Greetings,
Marcus

On 03.03.2014 06:53, Activecat wrote:
> Dear Sir, Thank you very much.
> 
> What if, we want to stop the flow graph in the constructor of a
> block?
> 
> In work() we can just return -1. But in constructor, what value
> should be returned, also -1  ?
> 
> Regards, Activecat
> 
> 
> On Sun, Feb 2, 2014 at 9:05 PM, Martin Braun
>  wrote:
> 
>> On 01.02.2014 13:51, Activecat wrote:
>> 
>>> But the function stop() fails to work. The flow graph continue
>>> executing infinitely...
>>> 
>>> Question: How to stop the flow graph when this->d_complete ==
>>> true ?
>>> 
>> 
>> Return -1 (or WORK_DONE) in your work() function.
>> 
>> MB
>> 
>> 
>> ___ 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFEqdAAoJEAFxB7BbsDrLv84H/jghxvQXY6VcZPvRXs1BKmxp
Odr8p/ICE9rpcz21M6M0ILxqhKaOp5vlaG/n6UMM2fFU+Cf7RQQkFrVsEBcqUcGg
sgYjE+PmTuIbn6xg6mupAJdN1iVsztH+5qU/71SPxJjfwpnJjsJrzzGlQC6JhGIr
fPHDG5DLAS11Q8USSFAc5Y7vXI57rskCZ3/Qq1j+dTl5pgNLSzsccb4AmVBy2dCB
7mM1PIxAuTJgaeXbk85BEnhkwdI4HQzOS7phg53ChYIWMKs+WCsjk0weUNMj2VZt
rXdd137xZjkfPHyGJ73spjhJ7OHUW8NeQaNxauI8Uf45S6jnNFFx/vzD1EEgIV8=
=vI+z
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Unable to stop the flow graph after calling stop()

2014-03-03 Thread Activecat 
Dear Marcus,

Says, the constructor performed some basic checking on the constructor
arguments, then had found some fatal error (says, division by zero) and
decided to ban the flowgraph from being executed.

A workaround is to get the constructor to set a class variable to false,
says,
d_valid = false;

then in the work() it will check this d_valid as follows:

int work()
{
if ( ! d_valid )
   return -1
.
.  (other stuff as usual)
}


But isn't there a better way to do this ..?
(to ban the flowgraph from being executed within the constructor)

Please advise, thanks.

Regards,
Activecat



On Mon, Mar 3, 2014 at 5:25 PM, Marcus Müller  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Activecat,
>
> the constructor of a block must have been called before the block has
> been connect()ed; so there's no way a flowgraph is already running
> when your block's constructor is called.
>
> Greetings,
> Marcus
>
> On 03.03.2014 06:53, Activecat wrote:
> > Dear Sir, Thank you very much.
> >
> > What if, we want to stop the flow graph in the constructor of a
> > block?
> >
> > In work() we can just return -1. But in constructor, what value
> > should be returned, also -1  ?
> >
> > Regards, Activecat
> >
> >
> > On Sun, Feb 2, 2014 at 9:05 PM, Martin Braun
> >  wrote:
> >
> >> On 01.02.2014 13:51, Activecat wrote:
> >>
> >>> But the function stop() fails to work. The flow graph continue
> >>> executing infinitely...
> >>>
> >>> Question: How to stop the flow graph when this->d_complete ==
> >>> true ?
> >>>
> >>
> >> Return -1 (or WORK_DONE) in your work() function.
> >>
> >> MB
> >>
> >>
> >> ___ 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
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTFEqdAAoJEAFxB7BbsDrLv84H/jghxvQXY6VcZPvRXs1BKmxp
> Odr8p/ICE9rpcz21M6M0ILxqhKaOp5vlaG/n6UMM2fFU+Cf7RQQkFrVsEBcqUcGg
> sgYjE+PmTuIbn6xg6mupAJdN1iVsztH+5qU/71SPxJjfwpnJjsJrzzGlQC6JhGIr
> fPHDG5DLAS11Q8USSFAc5Y7vXI57rskCZ3/Qq1j+dTl5pgNLSzsccb4AmVBy2dCB
> 7mM1PIxAuTJgaeXbk85BEnhkwdI4HQzOS7phg53ChYIWMKs+WCsjk0weUNMj2VZt
> rXdd137xZjkfPHyGJ73spjhJ7OHUW8NeQaNxauI8Uf45S6jnNFFx/vzD1EEgIV8=
> =vI+z
> -END PGP SIGNATURE-
>
> ___
> 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] Unable to stop the flow graph after calling stop()

2014-03-03 Thread Miklos Maroti 
Dear Activecat,

Throw an exception. It will kill the application.

Miklos

On Mon, Mar 3, 2014 at 11:57 AM, Activecat  wrote:
> Dear Marcus,
>
> Says, the constructor performed some basic checking on the constructor
> arguments, then had found some fatal error (says, division by zero) and
> decided to ban the flowgraph from being executed.
>
> A workaround is to get the constructor to set a class variable to false,
> says,
> d_valid = false;
>
> then in the work() it will check this d_valid as follows:
>
> int work()
> {
> if ( ! d_valid )
>return -1
> .
> .  (other stuff as usual)
> }
>
>
> But isn't there a better way to do this ..?
> (to ban the flowgraph from being executed within the constructor)
>
> Please advise, thanks.
>
> Regards,
> Activecat
>
>
>
> On Mon, Mar 3, 2014 at 5:25 PM, Marcus Müller  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Activecat,
>>
>> the constructor of a block must have been called before the block has
>> been connect()ed; so there's no way a flowgraph is already running
>> when your block's constructor is called.
>>
>> Greetings,
>> Marcus
>>
>> On 03.03.2014 06:53, Activecat wrote:
>> > Dear Sir, Thank you very much.
>> >
>> > What if, we want to stop the flow graph in the constructor of a
>> > block?
>> >
>> > In work() we can just return -1. But in constructor, what value
>> > should be returned, also -1  ?
>> >
>> > Regards, Activecat
>> >
>> >
>> > On Sun, Feb 2, 2014 at 9:05 PM, Martin Braun
>> >  wrote:
>> >
>> >> On 01.02.2014 13:51, Activecat wrote:
>> >>
>> >>> But the function stop() fails to work. The flow graph continue
>> >>> executing infinitely...
>> >>>
>> >>> Question: How to stop the flow graph when this->d_complete ==
>> >>> true ?
>> >>>
>> >>
>> >> Return -1 (or WORK_DONE) in your work() function.
>> >>
>> >> MB
>> >>
>> >>
>> >> ___ 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
>> >
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJTFEqdAAoJEAFxB7BbsDrLv84H/jghxvQXY6VcZPvRXs1BKmxp
>> Odr8p/ICE9rpcz21M6M0ILxqhKaOp5vlaG/n6UMM2fFU+Cf7RQQkFrVsEBcqUcGg
>> sgYjE+PmTuIbn6xg6mupAJdN1iVsztH+5qU/71SPxJjfwpnJjsJrzzGlQC6JhGIr
>> fPHDG5DLAS11Q8USSFAc5Y7vXI57rskCZ3/Qq1j+dTl5pgNLSzsccb4AmVBy2dCB
>> 7mM1PIxAuTJgaeXbk85BEnhkwdI4HQzOS7phg53ChYIWMKs+WCsjk0weUNMj2VZt
>> rXdd137xZjkfPHyGJ73spjhJ7OHUW8NeQaNxauI8Uf45S6jnNFFx/vzD1EEgIV8=
>> =vI+z
>> -END PGP SIGNATURE-
>>
>> ___
>> 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

Re: [Discuss-gnuradio] Unable to stop the flow graph after calling stop()

2014-03-03 Thread Marcus Müller 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Activecat,

as Miklos wrote: Let your Constructor throw an exception.
For a little detail on that, refer to
http://www.parashift.com/c++-faq-lite/ctors-can-throw.html .
You can surround your block construction with a try{}catch-clause, and
handle your error, so your application may deal with that gracefully
(instead of just dying).

Another common method of dealing with stuff like this is, if you
really have complex constructor arguments and might need to check if
they make sense in multiple places
- - let your class have a static method validate_arguments(...) that
returns true or false,
- - let your c'tor call that and throw an exception when it's false, and
- - use that unbound method (that is calling
activecats_class::validate_arguments() rather than calling
instance_of_that_class.validate_arguments()) from wherever you want to
calculate arguments.

Greetings,
Marcus

On 03.03.2014 12:02, Miklos Maroti wrote:
> Dear Activecat,
> 
> Throw an exception. It will kill the application.
> 
> Miklos
> 
> On Mon, Mar 3, 2014 at 11:57 AM, Activecat 
> wrote:
>> Dear Marcus,
>> 
>> Says, the constructor performed some basic checking on the
>> constructor arguments, then had found some fatal error (says,
>> division by zero) and decided to ban the flowgraph from being
>> executed.
>> 
>> A workaround is to get the constructor to set a class variable to
>> false, says, d_valid = false;
>> 
>> then in the work() it will check this d_valid as follows:
>> 
>> int work() { if ( ! d_valid ) return -1 . .
>> (other stuff as usual) }
>> 
>> 
>> But isn't there a better way to do this ..? (to ban the flowgraph
>> from being executed within the constructor)
>> 
>> Please advise, thanks.
>> 
>> Regards, Activecat
>> 
>> 
>> 
>> On Mon, Mar 3, 2014 at 5:25 PM, Marcus Müller
>>  wrote:
>>> 
> Activecat,
> 
> the constructor of a block must have been called before the block
> has been connect()ed; so there's no way a flowgraph is already
> running when your block's constructor is called.
> 
> Greetings, Marcus
> 
> On 03.03.2014 06:53, Activecat wrote:
> Dear Sir, Thank you very much.
> 
> What if, we want to stop the flow graph in the constructor
> of a block?
> 
> In work() we can just return -1. But in constructor, what
> value should be returned, also -1  ?
> 
> Regards, Activecat
> 
> 
> On Sun, Feb 2, 2014 at 9:05 PM, Martin Braun 
>  wrote:
> 
>> On 01.02.2014 13:51, Activecat wrote:
>> 
>>> But the function stop() fails to work. The flow graph
>>> continue executing infinitely...
>>> 
>>> Question: How to stop the flow graph when
>>> this->d_complete == true ?
>>> 
>> 
>> Return -1 (or WORK_DONE) in your work() function.
>> 
>> MB
>> 
>> 
>> ___
>> 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
>> mailing list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFGmXAAoJEAFxB7BbsDrLOLAIAJUgbhHeABDD9bDgCjJYRIhu
VzbVgZPo0bnPVfNGkojrO5wRTSzjHbCqQFkKbl4JCPLK6+IPq/9mL+iDffPQ9Aic
IGZLhq/ep8LwfiDjjh6D6BNQYmHqa6hRLPkHBzETmKqvBK5258b86IgedJNIDJF7
+qfVZWQsi3FDUyGSD6fVRHOUkfKT3naR0FqhipxtMRWFprBRrovMV23IqbVMdDQv
WfxeWyNoJMpYjXPT+S/pt7h9kxKUbcZK4aOWwuhnwmTahFcfcx+GCIc54UQHegVR
/WvOD1LNiYIXLJg6wEssN783OXbMqzWTaTl0+CFf6NWO4jQQFaAtoiUk3+EjXIQ=
=9pRp
-END PGP SIGNATURE-

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

[Discuss-gnuradio] catching unrecognized exception

2014-03-03 Thread Nemanja Savic 
Hi all guys,

I have a block which is responsible to receive certain messages from other
blocks and to write the data from the message into database. Sometimes the
following exception occures and the block stops writing into database:

thread[thread-per-block[0]: ]: caught
unrecognized exception

The structure of the block is really simple:

def handle_msg(self, msg):
message = pmt.pmt_symbol_to_string(msg)
msg_lines = message.split('\n')
try:
sensor_id = msg_lines[0]
vendor = msg_lines[2]
sensor_type = msg_lines[3]
time = msg_lines[1]
#try:
querry = "INSERT INTO `%s`.`%s` (`id` ,`sens_id` ,`vendor`,
`sensor_type`, `det_id`) VALUES (NULL , '%s', '%s', '%s','%s');" %
(self._db_name, self._det_table, sensor_id, vendor, sensor_type, self._id)
#print querry
cur = self._con.cursor()
cur.execute(querry)
except mdb.Error, e:
print "Unexpected error while trying to insert into table"
print msg_lines
print 50*'-'
print "Error %d: %s" % (e.args[0],e.args[1])
sys.exit(1)

Is there any way to track this problem and find the cause?

Best regards,

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

Re: [Discuss-gnuradio] Modifying gr-air-modes to work with Nutaq's Zepto/Pico

2014-03-03 Thread tristan.martin 
Hello Adrien,

You can simply replace the UHD functions invoked by their Nutaq equivalent.
This is very easy and straight forward.

There are two blogs on the subject, one for C language, one for GRC flow
graphs.
http://nutaq.com/en/blog/comparison-nutaq-api-and-usrp-hardware-driver
http://nutaq.com/en/blog/how-port-existing-gnu-radio-waveform-picosdr-less-2-minutes

I had a quick look to gr-air-modes-master, it doesn’t seem to have a .grc,
so you will do the UHD->Nutaq replacements in the Python implementation
(gr-air-modes-master\python\radio.py). The Nutaq API and FPGA cores come
with in-depth documentation that explains each function (“doc” folder). But
one quick way to get started is by comparing (using diff or Beyond Compare)
the Pyton generated form a basic GRC example (eg: uhd_rx_dpsk.uhd.py from
basic GR install) where you replace the UHD blocks with Nutaq blocks. The
delta obtained is the list of UHD python function along with their Nutaq
equivalent.

In Radio.py (gr-air-modes-master), copy the UHD implementation starting at
line 144 and paste it into a new “elsif” at line 177:
elif options.source == "zeptosdr":  #using Nutaq ZeptoSDR
Then replace the “from gnuradio import uhd” and “uhd.usrp_source()” by their
Nutaq equivalent: “import Nutaq” and “nutaq.rtdex_source()” respectively.

Repeat with all the RTDEx and Radio420x configuration functions listed
earlier with diff or Beyond Compare (set_center_freq , set_samp_rate,
set_gain, etc…).

Then, remake the proper connexions by replacing 
self.connect((self.uhd_usrp_source_0, 0), (…))
with
self.connect((self.nutaq_rtdex_source_0, 0), (…))

Finally, do not hesitate to connect our tech support helpdesk if you run
into problems understanding an API function when working on your code.

http://nutaq.com/en/support

Tristan




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Modifying-gr-air-modes-to-work-with-Nutaq-s-Zepto-Pico-tp46634p46671.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] Unable to stop the flow graph after calling stop()

2014-03-03 Thread Martin Braun 
On 03/03/2014 12:37 PM, Marcus Müller wrote:
> Hi Activecat,
> 
> as Miklos wrote: Let your Constructor throw an exception.
> For a little detail on that, refer to
> http://www.parashift.com/c++-faq-lite/ctors-can-throw.html .
> You can surround your block construction with a try{}catch-clause, and
> handle your error, so your application may deal with that gracefully
> (instead of just dying).

Also, grep for throw in the impl files for an example, we do that a lot
in GNU Radio.

M

> Another common method of dealing with stuff like this is, if you
> really have complex constructor arguments and might need to check if
> they make sense in multiple places
> - let your class have a static method validate_arguments(...) that
> returns true or false,
> - let your c'tor call that and throw an exception when it's false, and
> - use that unbound method (that is calling
> activecats_class::validate_arguments() rather than calling
> instance_of_that_class.validate_arguments()) from wherever you want to
> calculate arguments.
> 
> Greetings,
> Marcus
> 
> On 03.03.2014 12:02, Miklos Maroti wrote:
>> Dear Activecat,
> 
>> Throw an exception. It will kill the application.
> 
>> Miklos
> 
>> On Mon, Mar 3, 2014 at 11:57 AM, Activecat 
>> wrote:
>>> Dear Marcus,
>>>
>>> Says, the constructor performed some basic checking on the
>>> constructor arguments, then had found some fatal error (says,
>>> division by zero) and decided to ban the flowgraph from being
>>> executed.
>>>
>>> A workaround is to get the constructor to set a class variable to
>>> false, says, d_valid = false;
>>>
>>> then in the work() it will check this d_valid as follows:
>>>
>>> int work() { if ( ! d_valid ) return -1 . .
>>> (other stuff as usual) }
>>>
>>>
>>> But isn't there a better way to do this ..? (to ban the flowgraph
>>> from being executed within the constructor)
>>>
>>> Please advise, thanks.
>>>
>>> Regards, Activecat
>>>
>>>
>>>
>>> On Mon, Mar 3, 2014 at 5:25 PM, Marcus Müller
>>>  wrote:

>> Activecat,
> 
>> the constructor of a block must have been called before the block
>> has been connect()ed; so there's no way a flowgraph is already
>> running when your block's constructor is called.
> 
>> Greetings, Marcus
> 
>> On 03.03.2014 06:53, Activecat wrote:
>> Dear Sir, Thank you very much.
>>
>> What if, we want to stop the flow graph in the constructor
>> of a block?
>>
>> In work() we can just return -1. But in constructor, what
>> value should be returned, also -1  ?
>>
>> Regards, Activecat
>>
>>
>> On Sun, Feb 2, 2014 at 9:05 PM, Martin Braun 
>>  wrote:
>>
>>> On 01.02.2014 13:51, Activecat wrote:
>>>
 But the function stop() fails to work. The flow graph
 continue executing infinitely...

 Question: How to stop the flow graph when
 this->d_complete == true ?

>>>
>>> Return -1 (or WORK_DONE) in your work() function.
>>>
>>> MB
>>>
>>>
>>> ___
>>> 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
>>> 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

Re: [Discuss-gnuradio] Unable to stop the flow graph after calling stop()

2014-03-03 Thread Activecat 
Dear gurus,
I got it, thank you very much !

Regards,
Activecat


On Mon, Mar 3, 2014 at 9:11 PM, Martin Braun  wrote:

> On 03/03/2014 12:37 PM, Marcus Müller wrote:
> > Hi Activecat,
> >
> > as Miklos wrote: Let your Constructor throw an exception.
> > For a little detail on that, refer to
> > http://www.parashift.com/c++-faq-lite/ctors-can-throw.html .
> > You can surround your block construction with a try{}catch-clause, and
> > handle your error, so your application may deal with that gracefully
> > (instead of just dying).
>
> Also, grep for throw in the impl files for an example, we do that a lot
> in GNU Radio.
>
> M
>
> > Another common method of dealing with stuff like this is, if you
> > really have complex constructor arguments and might need to check if
> > they make sense in multiple places
> > - let your class have a static method validate_arguments(...) that
> > returns true or false,
> > - let your c'tor call that and throw an exception when it's false, and
> > - use that unbound method (that is calling
> > activecats_class::validate_arguments() rather than calling
> > instance_of_that_class.validate_arguments()) from wherever you want to
> > calculate arguments.
> >
> > Greetings,
> > Marcus
> >
> > On 03.03.2014 12:02, Miklos Maroti wrote:
> >> Dear Activecat,
> >
> >> Throw an exception. It will kill the application.
> >
> >> Miklos
> >
> >> On Mon, Mar 3, 2014 at 11:57 AM, Activecat 
> >> wrote:
> >>> Dear Marcus,
> >>>
> >>> Says, the constructor performed some basic checking on the
> >>> constructor arguments, then had found some fatal error (says,
> >>> division by zero) and decided to ban the flowgraph from being
> >>> executed.
> >>>
> >>> A workaround is to get the constructor to set a class variable to
> >>> false, says, d_valid = false;
> >>>
> >>> then in the work() it will check this d_valid as follows:
> >>>
> >>> int work() { if ( ! d_valid ) return -1 . .
> >>> (other stuff as usual) }
> >>>
> >>>
> >>> But isn't there a better way to do this ..? (to ban the flowgraph
> >>> from being executed within the constructor)
> >>>
> >>> Please advise, thanks.
> >>>
> >>> Regards, Activecat
> >>>
> >>>
> >>>
> >>> On Mon, Mar 3, 2014 at 5:25 PM, Marcus Müller
> >>>  wrote:
> 
> >> Activecat,
> >
> >> the constructor of a block must have been called before the block
> >> has been connect()ed; so there's no way a flowgraph is already
> >> running when your block's constructor is called.
> >
> >> Greetings, Marcus
> >
> >> On 03.03.2014 06:53, Activecat wrote:
> >> Dear Sir, Thank you very much.
> >>
> >> What if, we want to stop the flow graph in the constructor
> >> of a block?
> >>
> >> In work() we can just return -1. But in constructor, what
> >> value should be returned, also -1  ?
> >>
> >> Regards, Activecat
> >>
> >>
> >> On Sun, Feb 2, 2014 at 9:05 PM, Martin Braun
> >>  wrote:
> >>
> >>> On 01.02.2014 13:51, Activecat wrote:
> >>>
>  But the function stop() fails to work. The flow graph
>  continue executing infinitely...
> 
>  Question: How to stop the flow graph when
>  this->d_complete == true ?
> 
> >>>
> >>> Return -1 (or WORK_DONE) in your work() function.
> >>>
> >>> MB
> >>>
> >>>
> >>> ___
> >>> 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
> >>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem with "TCP Source" module in the client mode

2014-03-03 Thread Igor Volodin 

Hi all!

I am trying to build following simple scheme:

Signal source --> TCP Sink (server mode)  < TCP Source (client mode) 
--> GUI Scope Sink


It's strange but this simple scheme isn't working.


sockstat shows me:

USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
igor python2.7  56206 11 tcp4   10.21.32.6:21950 10.21.32.6:12000

Looks like communication between tcp sink and tcp source blocks has been 
established, but tcpdump doesn't show any packets


I decided to check first part of my scheme (Signal source + TCP Sink), 
and connected using netcat utility to the tcp sink port. All looks OK, 
the values come as expected.


Can anybody explain, why this simple scheme doesn't work?


Best regards,
Igor




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

Re: [Discuss-gnuradio] The GMSK demodulation

2014-03-03 Thread Perper 
W dniu 28.02.2014 15:31, zhenhua han pisze:
> Hi,
>
> As I have known, GSM uses GMSK modulation which BT = 0.3 and it
> uses Viterbi algorithm for demodulation. And I took a look at the code
> of GMSK demod code in GNU Radio, it use quadrature_demod but not
> Viterbi as demodulation method. So which one is better in doing
> demodulating GMSK?
>
> Moreover, GSM uses Viterbi algorithm to decode the convolution
> encoding. Would it be possible to use quadrature_demod to demodulate
> GSM signal instead of Viterbi? What about the convolution decoding
> part (maybe by some other method)?
>
> Cheers,
> Zhenhua
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hello all,

Regarding usage of viterbi algorithm for maximum likelihood sequence
estimation in GSM - you may look at and try gsm-receiver that I once
submitted to airprobe. I've prepared version where I thrown out all of
decoding stuff and left only synchronization, channel estimation and
detection of GMKS symbols with viterbi algorithm. It's available for
download in here:
https://github.com/Jakotako/gr-gsm

It compiles with newest gnu-radio and it has gnuradio companion xml file
as well. It can be easily connected to different sources in gnuradio
(file, rtl-sdr, usrp). I've corrected some issues with synchronization
and turned off frequency offset correction that introduced instability
of the receiver. There are examples of in the "examples" directory.

P.S. If someone applied Achilleas's implementation of viterbi algorithm
from gnu-radio in GSM I'm very interested to see how it can be done.

--
Best Regards,
Piotr Krysik

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

Re: [Discuss-gnuradio] The GMSK demodulation

2014-03-03 Thread Perper 
W dniu 28.02.2014 15:31, zhenhua han pisze:
> Hi,
>
> As I have known, GSM uses GMSK modulation which BT = 0.3 and it
> uses Viterbi algorithm for demodulation. And I took a look at the code
> of GMSK demod code in GNU Radio, it use quadrature_demod but not
> Viterbi as demodulation method. So which one is better in doing
> demodulating GMSK?
>
> Moreover, GSM uses Viterbi algorithm to decode the convolution
> encoding. Would it be possible to use quadrature_demod to demodulate
> GSM signal instead of Viterbi? What about the convolution decoding
> part (maybe by some other method)?
>
> Cheers,
> Zhenhua
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hello all,

Regarding usage of viterbi algorithm for maximum likelihood sequence
estimation in GSM - you may look at and try gsm-receiver that I once
submitted to airprobe. I've prepared version where I thrown out all of
decoding stuff and left only synchronization, channel estimation and
detection of bits with viterbi algorithm. It's available for download in
here:
https://github.com/Jakotako/gr-gsm

It compiles with newest gnu-radio and it has gnuradio companion xml file
as well. It can be easily connected to different sources in gnuradio
(file, rtl-sdr, usrp) and it has a message sink where burst bits and
gsmtap headers are sent. I've corrected some issues with synchronization
and turned off frequency offset correction that introduced instability
of the receiver. After compiling and installing you can start with examples.

--
Best Regards,
Piotr Krysik

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

[Discuss-gnuradio] GSoC 2014 project "Wireless Networks In-the-Loop" and "Channel Sounder"

2014-03-03 Thread achuth pv 
Hi everyone,

My name is Achuth PV,  first year Master of Technology student in
Communication and Signal Processing, Indian Institute of Technology,
Bombay, India.

I am really interested to work in the GSoC project "Wireless Networks
In-the-Loop" and "Channel Sounder"( proposed in 2012 ).

=

*Wireless Networks In-the-Loop*

The basic idea behind "Wireless Networks In-the-Loop" (WiNeLo) is to build
a GR-based network emulator. This implies the modeling of the underlying
SDR hardware, the individual channels & interference characteristics, as
well as the timing behavior (produce correct amount of noise samples if no
node is transmitting). The project already started in 2011 and as a
outcome, the basic functionality -- the framework with client-server based
"sample dispatcher" as well as some example hardware & channel models --
has already been implemented in the gr-winelo OOT, which will be published
on github soon. See
http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm for
a quick introdcution to "Wireless Networks In-the-Loop".
ObjectivesThere are various tasks covering several areas. Possible
(sub-)projects are:

   - (Signal Processing) Implementation of new hardware/channel models like
   a SDR platform/specific daughterboards or reference channels.
   - (Optimization & Performance) Improve performance of existing
   implementation (port python code to C/C++, develop new mechanisms to
   collect & distribute samples between several nodes).
   - (Signal Processing & Development Tools) Implementation of new
   development tools like "breakpoints on the air link" (pause the entire
   emulation if certain criteria (BER, SNR, interference/collisions) is
   fulfilled on the virtual channel/at single nodes).

Potential mentor(s)

Nico Otterbach
=
*Channel Sounder (Proposed in 2012)*

*Details*: Channel sounding describes the process of measuring a multipath
propagation channel and obtain information about excess delay, Doppler
spread and fading properties. The final product should make use of USRPs
for channel sounding (the high timing constraints require use of the FPGA)
and provide a complete measurement tool which can be used to gather
statistics about mobile communication channels.
*Knowledge prerequisite:* Digital signal processing basics, FPGA basics
*Access to USRPs required.*

*=*

My fields of interest are signal processing, wireless and digital
communication, hardware and software programming and data networks.

I am really comfortable in programming using C/C++, java, matlab, assembly
language, VHDL and I have understanding of Python, CUDA, git. I am also
comfortable in working in Linux. I am a team player and a fast learner and
has got good commitment. My B Tech final year project was "Implementation
and comparison of various DCT architectures on FPGA using VHDL"

 I got exposed to GnuRadio for the first time as a part of a course project
in Wireless and Mobile Communication taken as a part of my masters.

I want to contribute a lot to the open source world and I want GSoC to be
the stepping stone for that.

Can any one please tell me how to start working on these projects.

Thanks in Advance

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

Re: [Discuss-gnuradio] GSoC 2014 project "Wireless Networks In-the-Loop" and "Channel Sounder"

2014-03-03 Thread Aditya Dhananjay 
Hi Achuth,

Channel sounding with USRP radios and GNU Radio has been done by some folks
at Rutgers and AT&T Labs.

http://arxiv.org/pdf/1211.4940v1.pdf

It might be a good idea to contact Nazmul Islam (CCed) about this project.
Good luck.

best,
aditya



On Mon, Mar 3, 2014 at 3:05 PM, achuth pv  wrote:

> Hi everyone,
>
> My name is Achuth PV,  first year Master of Technology student in
> Communication and Signal Processing, Indian Institute of Technology,
> Bombay, India.
>
> I am really interested to work in the GSoC project "Wireless Networks
> In-the-Loop" and "Channel Sounder"( proposed in 2012 ).
>
> =
>
> *Wireless Networks In-the-Loop*
>
> The basic idea behind "Wireless Networks In-the-Loop" (WiNeLo) is to build
> a GR-based network emulator. This implies the modeling of the underlying
> SDR hardware, the individual channels & interference characteristics, as
> well as the timing behavior (produce correct amount of noise samples if no
> node is transmitting). The project already started in 2011 and as a
> outcome, the basic functionality -- the framework with client-server based
> "sample dispatcher" as well as some example hardware & channel models --
> has already been implemented in the gr-winelo OOT, which will be published
> on github soon. See
> http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm 
> for
> a quick introdcution to "Wireless Networks In-the-Loop".
>  ObjectivesThere are various tasks covering several areas. Possible
> (sub-)projects are:
>
>- (Signal Processing) Implementation of new hardware/channel models
>like a SDR platform/specific daughterboards or reference channels.
>- (Optimization & Performance) Improve performance of existing
>implementation (port python code to C/C++, develop new mechanisms to
>collect & distribute samples between several nodes).
>- (Signal Processing & Development Tools) Implementation of new
>development tools like "breakpoints on the air link" (pause the entire
>emulation if certain criteria (BER, SNR, interference/collisions) is
>fulfilled on the virtual channel/at single nodes).
>
> Potential mentor(s)
>
> Nico Otterbach
> =
> *Channel Sounder (Proposed in 2012)*
>
> *Details*: Channel sounding describes the process of measuring a
> multipath propagation channel and obtain information about excess delay,
> Doppler spread and fading properties. The final product should make use of
> USRPs for channel sounding (the high timing constraints require use of the
> FPGA) and provide a complete measurement tool which can be used to gather
> statistics about mobile communication channels.
> *Knowledge prerequisite:* Digital signal processing basics, FPGA basics
> *Access to USRPs required.*
>
> *=*
>
> My fields of interest are signal processing, wireless and digital
> communication, hardware and software programming and data networks.
>
> I am really comfortable in programming using C/C++, java, matlab, assembly
> language, VHDL and I have understanding of Python, CUDA, git. I am also
> comfortable in working in Linux. I am a team player and a fast learner and
> has got good commitment. My B Tech final year project was "Implementation
> and comparison of various DCT architectures on FPGA using VHDL"
>
>  I got exposed to GnuRadio for the first time as a part of a course
> project in Wireless and Mobile Communication taken as a part of my masters.
>
> I want to contribute a lot to the open source world and I want GSoC to be
> the stepping stone for that.
>
> Can any one please tell me how to start working on these projects.
>
> Thanks in Advance
>
> Achuth
>
>
>
> ___
> 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] GSoC 2014 project "Wireless Networks In-the-Loop" and "Channel Sounder"

2014-03-03 Thread achuth pv 
Thanks Aditya


On 4 March 2014 02:02, Aditya Dhananjay  wrote:

> Hi Achuth,
>
> Channel sounding with USRP radios and GNU Radio has been done by some
> folks at Rutgers and AT&T Labs.
>
> http://arxiv.org/pdf/1211.4940v1.pdf
>
> It might be a good idea to contact Nazmul Islam (CCed) about this project.
> Good luck.
>
> best,
> aditya
>
>
>
> On Mon, Mar 3, 2014 at 3:05 PM, achuth pv  wrote:
>
>> Hi everyone,
>>
>> My name is Achuth PV,  first year Master of Technology student in
>> Communication and Signal Processing, Indian Institute of Technology,
>> Bombay, India.
>>
>> I am really interested to work in the GSoC project "Wireless Networks
>> In-the-Loop" and "Channel Sounder"( proposed in 2012 ).
>>
>> =
>>
>> *Wireless Networks In-the-Loop*
>>
>> The basic idea behind "Wireless Networks In-the-Loop" (WiNeLo) is to
>> build a GR-based network emulator. This implies the modeling of the
>> underlying SDR hardware, the individual channels & interference
>> characteristics, as well as the timing behavior (produce correct amount of
>> noise samples if no node is transmitting). The project already started in
>> 2011 and as a outcome, the basic functionality -- the framework with
>> client-server based "sample dispatcher" as well as some example hardware &
>> channel models -- has already been implemented in the gr-winelo OOT, which
>> will be published on github soon. See
>> http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm 
>> for
>> a quick introdcution to "Wireless Networks In-the-Loop".
>>  ObjectivesThere are various tasks covering several areas. Possible
>> (sub-)projects are:
>>
>>- (Signal Processing) Implementation of new hardware/channel models
>>like a SDR platform/specific daughterboards or reference channels.
>>- (Optimization & Performance) Improve performance of existing
>>implementation (port python code to C/C++, develop new mechanisms to
>>collect & distribute samples between several nodes).
>>- (Signal Processing & Development Tools) Implementation of new
>>development tools like "breakpoints on the air link" (pause the entire
>>emulation if certain criteria (BER, SNR, interference/collisions) is
>>fulfilled on the virtual channel/at single nodes).
>>
>> Potential mentor(s)
>>
>> Nico Otterbach
>> =
>> *Channel Sounder (Proposed in 2012)*
>>
>> *Details*: Channel sounding describes the process of measuring a
>> multipath propagation channel and obtain information about excess delay,
>> Doppler spread and fading properties. The final product should make use of
>> USRPs for channel sounding (the high timing constraints require use of the
>> FPGA) and provide a complete measurement tool which can be used to gather
>> statistics about mobile communication channels.
>> *Knowledge prerequisite:* Digital signal processing basics, FPGA basics
>> *Access to USRPs required.*
>>
>> *=*
>>
>> My fields of interest are signal processing, wireless and digital
>> communication, hardware and software programming and data networks.
>>
>> I am really comfortable in programming using C/C++, java, matlab,
>> assembly language, VHDL and I have understanding of Python, CUDA, git. I am
>> also comfortable in working in Linux. I am a team player and a fast learner
>> and has got good commitment. My B Tech final year project was
>> "Implementation and comparison of various DCT architectures on FPGA using
>> VHDL"
>>
>>  I got exposed to GnuRadio for the first time as a part of a course
>> project in Wireless and Mobile Communication taken as a part of my masters.
>>
>> I want to contribute a lot to the open source world and I want GSoC to be
>> the stepping stone for that.
>>
>> Can any one please tell me how to start working on these projects.
>>
>> Thanks in Advance
>>
>> Achuth
>>
>>
>>
>> ___
>> 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] Fwd: New Defects reported by Coverity Scan for GNURadio

2014-03-03 Thread Philip Balister 
The latest Coverity scan showed these new items. We should probably
double check them. The Null dereference is likely related to the order
in which some class methods get called.

The compare against zero of an unsigned number should be checked to make
sure that is what was really meant.

Philip



** CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
/var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/fft_filter.cc:
355 in gr::filter::kernel::fft_filter_ccf::fft_filter_ccf(int, const
std::vector> &, int)()

** CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
/var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/pfb_synthesizer_ccf_impl.cc:
225 in gr::filter::pfb_synthesizer_ccf_impl::set_channel_map(const
std::vector> &)()



*** CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
/var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/fft_filter.cc:
355 in gr::filter::kernel::fft_filter_ccf::fft_filter_ccf(int, const
std::vector> &, int)()
349
/**/
350
351
352   fft_filter_ccf::fft_filter_ccf(int decimation,
353  const std::vector &taps,
354  int nthreads)
>>> CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
>>> Assigning: "this->d_fwdfft" = "NULL".
355 : d_fftsize(-1), d_decimation(decimation), d_fwdfft(0),
356   d_invfft(0), d_nthreads(nthreads), d_xformed_taps(NULL)
357   {
358 set_taps(taps);
359   }
360


*** CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
/var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/pfb_synthesizer_ccf_impl.cc:
225 in gr::filter::pfb_synthesizer_ccf_impl::set_channel_map(const
std::vector> &)()
219 {
220   gr::thread::scoped_lock guard(d_mutex);
221
222   if(map.size() > 0) {
223 unsigned int max = (unsigned
int)*std::max_element(map.begin(), map.end());
224 unsigned int min = (unsigned
int)*std::min_element(map.begin(), map.end());
>>> CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
>>> This less-than-zero comparison of an unsigned value is never true. "min 
>>> < 0U".
225 if((max >= d_twox*d_numchans) || (min < 0)) {
226   throw
std::invalid_argument("pfb_synthesizer_ccf_impl::set_channel_map: map
range out of bounds.\n");
227 }
228 d_channel_map = map;
229
230 // Zero out fft buffer so that unused channels are always 0

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

Re: [Discuss-gnuradio] Fwd: New Defects reported by Coverity Scan for GNURadio

2014-03-03 Thread Tom Rondeau 
On Mon, Mar 3, 2014 at 4:58 PM, Philip Balister  wrote:
> The latest Coverity scan showed these new items. We should probably
> double check them. The Null dereference is likely related to the order
> in which some class methods get called.
>
> The compare against zero of an unsigned number should be checked to make
> sure that is what was really meant.
>
> Philip

Too late. I already pushed fixes for these and updated Coverity.

I noticed the defect emails and it's related to code I just pushed
this weekend, so it was easy enough for me to get them while they were
fresh in my mind.

Thanks for keeping on top of this, though.

Tom



> ** CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
> /var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/fft_filter.cc:
> 355 in gr::filter::kernel::fft_filter_ccf::fft_filter_ccf(int, const
> std::vector> &, int)()
>
> ** CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
> /var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/pfb_synthesizer_ccf_impl.cc:
> 225 in gr::filter::pfb_synthesizer_ccf_impl::set_channel_map(const
> std::vector> &)()
>
>
> 
> *** CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
> /var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/fft_filter.cc:
> 355 in gr::filter::kernel::fft_filter_ccf::fft_filter_ccf(int, const
> std::vector> &, int)()
> 349
> /**/
> 350
> 351
> 352   fft_filter_ccf::fft_filter_ccf(int decimation,
> 353  const std::vector &taps,
> 354  int nthreads)
 CID 1189412:  Explicit null dereferenced  (FORWARD_NULL)
 Assigning: "this->d_fwdfft" = "NULL".
> 355 : d_fftsize(-1), d_decimation(decimation), d_fwdfft(0),
> 356   d_invfft(0), d_nthreads(nthreads), d_xformed_taps(NULL)
> 357   {
> 358 set_taps(taps);
> 359   }
> 360
>
> 
> *** CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
> /var/lib/jenkins/jobs/GNURadio-master/workspace/gnuradio/gr-filter/lib/pfb_synthesizer_ccf_impl.cc:
> 225 in gr::filter::pfb_synthesizer_ccf_impl::set_channel_map(const
> std::vector> &)()
> 219 {
> 220   gr::thread::scoped_lock guard(d_mutex);
> 221
> 222   if(map.size() > 0) {
> 223 unsigned int max = (unsigned
> int)*std::max_element(map.begin(), map.end());
> 224 unsigned int min = (unsigned
> int)*std::min_element(map.begin(), map.end());
 CID 1189413:  Unsigned compared against 0  (NO_EFFECT)
 This less-than-zero comparison of an unsigned value is never true. 
 "min < 0U".
> 225 if((max >= d_twox*d_numchans) || (min < 0)) {
> 226   throw
> std::invalid_argument("pfb_synthesizer_ccf_impl::set_channel_map: map
> range out of bounds.\n");
> 227 }
> 228 d_channel_map = map;
> 229
> 230 // Zero out fft buffer so that unused channels are always 0
>
> ___
> 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] GSoC 2014 project "Wireless Networks In-the-Loop" and "Channel Sounder"

2014-03-03 Thread Martin Braun 

On 03.03.2014 21:32, Aditya Dhananjay wrote:

Hi Achuth,

Channel sounding with USRP radios and GNU Radio has been done by some
folks at Rutgers and AT&T Labs.

http://arxiv.org/pdf/1211.4940v1.pdf


Achuth, Aditya,

channel sounding is not really what this project is about (although it's 
a small part, sure).


I recommend you watch the FOSDEM video and read the papers, then come 
back with specific questions.


Martin



It might be a good idea to contact Nazmul Islam (CCed) about this
project. Good luck.

best,
aditya



On Mon, Mar 3, 2014 at 3:05 PM, achuth pv mailto:achut...@gmail.com>> wrote:

Hi everyone,

My name is Achuth PV,  first year Master of Technology student in
Communication and Signal Processing, Indian Institute of Technology,
Bombay, India.

I am really interested to work in the GSoC project "Wireless
Networks In-the-Loop" and "Channel Sounder"( proposed in 2012 ).

=

*Wireless Networks In-the-Loop*

The basic idea behind "Wireless Networks In-the-Loop" (WiNeLo) is to
build a GR-based network emulator. This implies the modeling of the
underlying SDR hardware, the individual channels & interference
characteristics, as well as the timing behavior (produce correct
amount of noise samples if no node is transmitting). The project
already started in 2011 and as a outcome, the basic functionality --
the framework with client-server based "sample dispatcher" as well
as some example hardware & channel models -- has already been
implemented in the gr-winelo OOT, which will be published on github
soon.

Seehttp://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm 
for
a quick introdcution to "Wireless Networks In-the-Loop".


  Objectives

There are various tasks covering several areas. Possible
(sub-)projects are:

  * (Signal Processing) Implementation of new hardware/channel
models like a SDR platform/specific daughterboards or reference
channels.
  * (Optimization & Performance) Improve performance of existing
implementation (port python code to C/C++, develop new
mechanisms to collect & distribute samples between several nodes).
  * (Signal Processing & Development Tools) Implementation of new
development tools like "breakpoints on the air link" (pause the
entire emulation if certain criteria (BER, SNR,
interference/collisions) is fulfilled on the virtual channel/at
single nodes).


  Potential mentor(s)

Nico Otterbach

=
*Channel Sounder (Proposed in 2012)*

*Details*: Channel sounding describes the process of measuring a
multipath propagation channel and obtain information about excess
delay, Doppler spread and fading properties. The final product
should make use of USRPs for channel sounding (the high timing
constraints require use of the FPGA) and provide a complete
measurement tool which can be used to gather statistics about mobile
communication channels.
*Knowledge prerequisite:* Digital signal processing basics, FPGA basics
*Access to USRPs required.*
*
*
*=*

My fields of interest are signal processing, wireless and digital
communication, hardware and software programming and data networks.

I am really comfortable in programming using C/C++, java, matlab,
assembly language, VHDL and I have understanding of Python, CUDA,
git. I am also comfortable in working in Linux. I am a team player
and a fast learner and has got good commitment. My B Tech final year
project was "Implementation and comparison of various DCT
architectures on FPGA using VHDL"

  I got exposed to GnuRadio for the first time as a part of a course
project in Wireless and Mobile Communication taken as a part of my
masters.

I want to contribute a lot to the open source world and I want GSoC
to be the stepping stone for that.

Can any one please tell me how to start working on these projects.

Thanks in Advance

Achuth


___
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] blocks with message input and output only

2014-03-03 Thread Miklos Maroti 
Hi Guys,

How to write blocks that have only message input and outputs only? I
have derived from gr:block, and in most cases it seems to work, but if
I put together a test that has no streams, then the whole graph stops
I think prematurely. How to ensure that a flow graph works with
messages only?

Miklos

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

Re: [Discuss-gnuradio] blocks with message input and output only

2014-03-03 Thread Miklos Maroti 
Sorry, everything works as expected (needs a little wait at the
beginning). Miklos

On Tue, Mar 4, 2014 at 1:09 AM, Miklos Maroti  wrote:
> Hi Guys,
>
> How to write blocks that have only message input and outputs only? I
> have derived from gr:block, and in most cases it seems to work, but if
> I put together a test that has no streams, then the whole graph stops
> I think prematurely. How to ensure that a flow graph works with
> messages only?
>
> Miklos

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

Re: [Discuss-gnuradio] The GMSK demodulation

2014-03-03 Thread zhenhua han 
Hi Perper,

I took a look at your code, and I found this

//set_frequency(d_freq_offset);

It seems you have turned off the the frequency offset correction as you
said.
Do you know the reason of the introduced instability by this part?

Best,
Zhenhua

2014-03-04 1:42 GMT+08:00 Perper :

> W dniu 28.02.2014 15:31, zhenhua han pisze:
> > Hi,
> >
> > As I have known, GSM uses GMSK modulation which BT = 0.3 and it
> > uses Viterbi algorithm for demodulation. And I took a look at the code
> > of GMSK demod code in GNU Radio, it use quadrature_demod but not
> > Viterbi as demodulation method. So which one is better in doing
> > demodulating GMSK?
> >
> > Moreover, GSM uses Viterbi algorithm to decode the convolution
> > encoding. Would it be possible to use quadrature_demod to demodulate
> > GSM signal instead of Viterbi? What about the convolution decoding
> > part (maybe by some other method)?
> >
> > Cheers,
> > Zhenhua
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> Hello all,
>
> Regarding usage of viterbi algorithm for maximum likelihood sequence
> estimation in GSM - you may look at and try gsm-receiver that I once
> submitted to airprobe. I've prepared version where I thrown out all of
> decoding stuff and left only synchronization, channel estimation and
> detection of bits with viterbi algorithm. It's available for download in
> here:
> https://github.com/Jakotako/gr-gsm
>
> It compiles with newest gnu-radio and it has gnuradio companion xml file
> as well. It can be easily connected to different sources in gnuradio
> (file, rtl-sdr, usrp) and it has a message sink where burst bits and
> gsmtap headers are sent. I've corrected some issues with synchronization
> and turned off frequency offset correction that introduced instability
> of the receiver. After compiling and installing you can start with
> examples.
>
> --
> Best Regards,
> Piotr Krysik
>
> ___
> 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] The GMSK demodulation

2014-03-03 Thread zhenhua han 
Hi guys,

I'm reading the code of Airprobe and I found this function.

double gsm_receiver_cf::compute_freq_offset(const gr_complex * input,
unsigned first_sample, unsigned last_sample)
{
  double phase_sum = 0;
  unsigned ii;

  for (ii = first_sample; ii < last_sample; ii++) {
double phase_diff = compute_phase_diff(input[ii], input[ii-1]) - (M_PI /
2) / d_OSR;
phase_sum += phase_diff;
  }

  double phase_offset = phase_sum / (last_sample - first_sample);
  double freq_offset = phase_offset * 1625000.0 / (12.0 * M_PI);
  return freq_offset;
}




It calculates the frequency offset with "freq_offset = phase_offset *
1625000.0 / (12.0 * M_PI);" I guess the (1625000.0/12*pi) equals
(1625000/6)/(2pi) and 1625/6 kbit/s is the modulation rate of GSM.

So, what is the principle of this calculation? How to calculate the
freq_offset with phase_offset. I tried some derivation but failed. Can
anyone help me to find out the derivation ?

Best wishes,
Zhenhua



2014-03-04 9:28 GMT+08:00 zhenhua han :

> Hi Perper,
>
> I took a look at your code, and I found this
>
> //set_frequency(d_freq_offset);
>
> It seems you have turned off the the frequency offset correction as you
> said.
> Do you know the reason of the introduced instability by this part?
>
> Best,
> Zhenhua
>
> 2014-03-04 1:42 GMT+08:00 Perper :
>
> W dniu 28.02.2014 15:31, zhenhua han pisze:
>> > Hi,
>> >
>> > As I have known, GSM uses GMSK modulation which BT = 0.3 and it
>> > uses Viterbi algorithm for demodulation. And I took a look at the code
>> > of GMSK demod code in GNU Radio, it use quadrature_demod but not
>> > Viterbi as demodulation method. So which one is better in doing
>> > demodulating GMSK?
>> >
>> > Moreover, GSM uses Viterbi algorithm to decode the convolution
>> > encoding. Would it be possible to use quadrature_demod to demodulate
>> > GSM signal instead of Viterbi? What about the convolution decoding
>> > part (maybe by some other method)?
>> >
>> > Cheers,
>> > Zhenhua
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> Hello all,
>>
>> Regarding usage of viterbi algorithm for maximum likelihood sequence
>> estimation in GSM - you may look at and try gsm-receiver that I once
>> submitted to airprobe. I've prepared version where I thrown out all of
>> decoding stuff and left only synchronization, channel estimation and
>> detection of bits with viterbi algorithm. It's available for download in
>> here:
>> https://github.com/Jakotako/gr-gsm
>>
>> It compiles with newest gnu-radio and it has gnuradio companion xml file
>> as well. It can be easily connected to different sources in gnuradio
>> (file, rtl-sdr, usrp) and it has a message sink where burst bits and
>> gsmtap headers are sent. I've corrected some issues with synchronization
>> and turned off frequency offset correction that introduced instability
>> of the receiver. After compiling and installing you can start with
>> examples.
>>
>> --
>> Best Regards,
>> Piotr Krysik
>>
>> ___
>> 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] The GMSK demodulation

2014-03-03 Thread zhenhua han 
2014-03-04 9:32 GMT+08:00 zhenhua han :

> Hi guys,
>
> I'm reading the code of Airprobe and I found this function.
>
> double gsm_receiver_cf::compute_freq_offset(const gr_complex * input,
> unsigned first_sample, unsigned last_sample)
> {
>   double phase_sum = 0;
>   unsigned ii;
>
>   for (ii = first_sample; ii < last_sample; ii++) {
> double phase_diff = compute_phase_diff(input[ii], input[ii-1]) -(M_PI
> / 2) / d_OSR;
> phase_sum += phase_diff;
>   }
>
>   double phase_offset = phase_sum / (last_sample - first_sample);
>   double freq_offset = phase_offset * 1625000.0 / (12.0 * M_PI);
>   return freq_offset;
> }
>
>
>
>
> It calculates the frequency offset with "freq_offset = phase_offset *
> 1625000.0 / (12.0 * M_PI);" I guess the (1625000.0/12*pi) equals
> (1625000/6)/(2pi) and 1625/6 kbit/s is the modulation rate of GSM.
>
> So, what is the principle of this calculation? How to calculate the
> freq_offset with phase_offset. I tried some derivation but failed. Can
> anyone help me to find out the derivation ?
>
> Best wishes,
> Zhenhua
>
>
>
BTW, this is a question I raised in my former email.(But no one replied...).
Maybe, there is some relationship between the  introduced instability and
my question.



>
> 2014-03-04 9:28 GMT+08:00 zhenhua han :
>
> Hi Perper,
>>
>> I took a look at your code, and I found this
>>
>> //set_frequency(d_freq_offset);
>>
>> It seems you have turned off the the frequency offset correction as you
>> said.
>> Do you know the reason of the introduced instability by this part?
>>
>> Best,
>> Zhenhua
>>
>> 2014-03-04 1:42 GMT+08:00 Perper :
>>
>> W dniu 28.02.2014 15:31, zhenhua han pisze:
>>> > Hi,
>>> >
>>> > As I have known, GSM uses GMSK modulation which BT = 0.3 and it
>>> > uses Viterbi algorithm for demodulation. And I took a look at the code
>>> > of GMSK demod code in GNU Radio, it use quadrature_demod but not
>>> > Viterbi as demodulation method. So which one is better in doing
>>> > demodulating GMSK?
>>> >
>>> > Moreover, GSM uses Viterbi algorithm to decode the convolution
>>> > encoding. Would it be possible to use quadrature_demod to demodulate
>>> > GSM signal instead of Viterbi? What about the convolution decoding
>>> > part (maybe by some other method)?
>>> >
>>> > Cheers,
>>> > Zhenhua
>>> >
>>> >
>>> > ___
>>> > Discuss-gnuradio mailing list
>>> > Discuss-gnuradio@gnu.org
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> Hello all,
>>>
>>> Regarding usage of viterbi algorithm for maximum likelihood sequence
>>> estimation in GSM - you may look at and try gsm-receiver that I once
>>> submitted to airprobe. I've prepared version where I thrown out all of
>>> decoding stuff and left only synchronization, channel estimation and
>>> detection of bits with viterbi algorithm. It's available for download in
>>> here:
>>> https://github.com/Jakotako/gr-gsm
>>>
>>> It compiles with newest gnu-radio and it has gnuradio companion xml file
>>> as well. It can be easily connected to different sources in gnuradio
>>> (file, rtl-sdr, usrp) and it has a message sink where burst bits and
>>> gsmtap headers are sent. I've corrected some issues with synchronization
>>> and turned off frequency offset correction that introduced instability
>>> of the receiver. After compiling and installing you can start with
>>> examples.
>>>
>>> --
>>> Best Regards,
>>> Piotr Krysik
>>>
>>> ___
>>> 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] The GMSK demodulation

2014-03-03 Thread Tom Tsou 
On Mon, Mar 3, 2014 at 8:32 PM, zhenhua han  wrote:
> I'm reading the code of Airprobe and I found this function.
>
> double gsm_receiver_cf::compute_freq_offset(const gr_complex * input,
> unsigned first_sample, unsigned last_sample)
>
~
>
> It calculates the frequency offset with "freq_offset = phase_offset *
> 1625000.0 / (12.0 * M_PI);" I guess the (1625000.0/12*pi) equals
> (1625000/6)/(2pi) and 1625/6 kbit/s is the modulation rate of GSM.
>
> So, what is the principle of this calculation? How to calculate the
> freq_offset with phase_offset. I tried some derivation but failed. Can
> anyone help me to find out the derivation ?

The offset is derived assuming the signal is a constant tone. The code
is averaging the phase shift between subsequent samples in a burst.
Frequency is the first derivative of phase with respect to time, so
the phase shift multiplied by the sample rate will give you the
frequency of the tone.

  -TT

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

Re: [Discuss-gnuradio] The GMSK demodulation

2014-03-03 Thread zhenhua han 
OK, I've got it.
Thank you for your help.

Cheers,
Zhenhua


2014-03-04 10:28 GMT+08:00 Tom Tsou :

> On Mon, Mar 3, 2014 at 8:32 PM, zhenhua han  wrote:
> > I'm reading the code of Airprobe and I found this function.
> >
> > double gsm_receiver_cf::compute_freq_offset(const gr_complex * input,
> > unsigned first_sample, unsigned last_sample)
> >
> ~
> >
> > It calculates the frequency offset with "freq_offset = phase_offset *
> > 1625000.0 / (12.0 * M_PI);" I guess the (1625000.0/12*pi) equals
> > (1625000/6)/(2pi) and 1625/6 kbit/s is the modulation rate of GSM.
> >
> > So, what is the principle of this calculation? How to calculate the
> > freq_offset with phase_offset. I tried some derivation but failed. Can
> > anyone help me to find out the derivation ?
>
> The offset is derived assuming the signal is a constant tone. The code
> is averaging the phase shift between subsequent samples in a burst.
> Frequency is the first derivative of phase with respect to time, so
> the phase shift multiplied by the sample rate will give you the
> frequency of the tone.
>
>   -TT
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FFTW3 runtime error

2014-03-03 Thread Activecat 
Dear Sir,

I am trying to build a custom block with FFT capability.
I use FFTW3, the FFT stuff runs well as a standalone program before
integrating into gnuradio.

Then I integrate the FFT function into the block, it compiles without any
error.
But when I run the flow graph in GRC, it produces following error message.

Generating: "/home/sgku/gnuradio/flow_graphs/top_block.py"
Executing: "/home/sgku/gnuradio/flow_graphs/top_block.py"
Traceback (most recent call last):
  File "/home/sgku/gnuradio/flow_graphs/top_block.py", line 18, in

import activecat
  File
"/usr/local/lib/python2.7/dist-packages/activecat/__init__.py", line 45, in

from activecat_swig import *
  File
"/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py", line
26, in 
_activecat_swig = swig_import_helper()
  File
"/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py", line
22, in swig_import_helper
_mod = imp.load_module('_activecat_swig', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-activecat.so: undefined
symbol: fftw_plan_dft_1d
>>> Done


Below is the implmentation source file:


namespace gr {
  namespace activecat {

fft1::sptr
fft1::make(int fft_size, int direction, bool fft_shift)
{
  return gnuradio::get_initial_sptr
(new fft1_impl(fft_size, direction, fft_shift));
}

// constructor
fft1_impl::fft1_impl(int fft_size, int direction, bool
fft_shift)
  : gr::sync_block("fft1",
  gr::io_signature::make( 1, 1, sizeof(gr_complex)),
  gr::io_signature::make( 1, 1,
sizeof(gr_complex))),
  d_N(fft_size),
  d_direction(direction),
  d_shift(fft_shift)
{
d_input = (fftw_complex*) fftw_malloc(
sizeof(fftw_complex) * d_N );
d_plan  = fftw_plan_dft_1d( d_N, d_input, d_input,
FFTW_BACKWARD, FFTW_ESTIMATE );  // later change FFTW_BACKWARD to
d_direction

set_output_multiple( d_N );
set_min_noutput_items( d_N );
}

// destructor
fft1_impl::~fft1_impl()
{ }

int
fft1_impl::work(
  int noutput_items,
  gr_vector_const_void_star &input_items,
  gr_vector_void_star &output_items)
{
const gr_complex  *in  =  (const gr_complex *)
input_items[0];
gr_complex*out =  (gr_complex *)
output_items[0];

for (int i=0; i < noutput_items; i++)
{
d_input[i][0] = in[i].real();
d_input[i][1] = in[i].imag();
}

fftw_execute( d_plan );

for (int i=0; i < noutput_items; i++)
{
out[i].real( d_input[i][0] );
out[i].imag( d_input[i][1] );
}


return noutput_items;
}
  } /* namespace activecat */
} /* namespace gr */



Question:
How to solve this error ?

Regards,
Activecat
active...@gmail.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FFTW3 runtime error

2014-03-03 Thread Activecat 
The implementation header file is as below:


#ifndef INCLUDED_ACTIVECAT_FFT1_IMPL_H
#define INCLUDED_ACTIVECAT_FFT1_IMPL_H

#include 
#include 

namespace gr {
  namespace activecat {

class fft1_impl : public fft1
{
 private:
   int d_N;
   int d_direction;
   int d_shift;

   fftw_complex *d_input;
   fftw_plan d_plan;

 public:
fft1_impl(int fft_size, int direction, bool fft_shift);
~fft1_impl();

int work(
   int noutput_items,
   gr_vector_const_void_star &input_items,
   gr_vector_void_star &output_items);
};

  } // namespace activecat
} // namespace gr

#endif /* INCLUDED_ACTIVECAT_FFT1_IMPL_H */



On Tue, Mar 4, 2014 at 1:55 PM, Activecat  wrote:

> Dear Sir,
>
> I am trying to build a custom block with FFT capability.
> I use FFTW3, the FFT stuff runs well as a standalone program before
> integrating into gnuradio.
>
> Then I integrate the FFT function into the block, it compiles without any
> error.
> But when I run the flow graph in GRC, it produces following error message.
>
> Generating: "/home/sgku/gnuradio/flow_graphs/top_block.py"
> Executing: "/home/sgku/gnuradio/flow_graphs/top_block.py"
> Traceback (most recent call last):
>   File "/home/sgku/gnuradio/flow_graphs/top_block.py", line 18, in
> 
> import activecat
>   File
> "/usr/local/lib/python2.7/dist-packages/activecat/__init__.py", line 45, in
> 
> from activecat_swig import *
>   File
> "/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py", line
> 26, in 
> _activecat_swig = swig_import_helper()
>   File
> "/usr/local/lib/python2.7/dist-packages/activecat/activecat_swig.py", line
> 22, in swig_import_helper
> _mod = imp.load_module('_activecat_swig', fp, pathname,
> description)
> ImportError: /usr/local/lib/libgnuradio-activecat.so: undefined
> symbol: fftw_plan_dft_1d
> >>> Done
>
>
> Below is the implmentation source file:
>
>
> namespace gr {
>   namespace activecat {
>
> fft1::sptr
> fft1::make(int fft_size, int direction, bool fft_shift)
> {
>   return gnuradio::get_initial_sptr
> (new fft1_impl(fft_size, direction, fft_shift));
> }
>
> // constructor
> fft1_impl::fft1_impl(int fft_size, int direction, bool
> fft_shift)
>   : gr::sync_block("fft1",
>   gr::io_signature::make( 1, 1,
> sizeof(gr_complex)),
>   gr::io_signature::make( 1, 1,
> sizeof(gr_complex))),
>   d_N(fft_size),
>   d_direction(direction),
>   d_shift(fft_shift)
> {
> d_input = (fftw_complex*) fftw_malloc(
> sizeof(fftw_complex) * d_N );
> d_plan  = fftw_plan_dft_1d( d_N, d_input, d_input,
> FFTW_BACKWARD, FFTW_ESTIMATE );  // later change FFTW_BACKWARD to
> d_direction
>
> set_output_multiple( d_N );
> set_min_noutput_items( d_N );
> }
>
> // destructor
> fft1_impl::~fft1_impl()
> { }
>
> int
> fft1_impl::work(
>   int noutput_items,
>   gr_vector_const_void_star &input_items,
>   gr_vector_void_star &output_items)
> {
> const gr_complex  *in  =  (const gr_complex *)
> input_items[0];
> gr_complex*out =  (gr_complex *)
> output_items[0];
>
> for (int i=0; i < noutput_items; i++)
> {
> d_input[i][0] = in[i].real();
> d_input[i][1] = in[i].imag();
> }
>
> fftw_execute( d_plan );
>
> for (int i=0; i < noutput_items; i++)
> {
> out[i].real( d_input[i][0] );
> out[i].imag( d_input[i][1] );
> }
>
>
> return noutput_items;
> }
>   } /* namespace activecat */
> } /* namespace gr */
>
>
>
>  Question:
> How to solve this error ?
>
> Regards,
> Activecat
> active...@gmail.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio