date:20160210

Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

2016-02-10 Thread Srinivasan T

Hi  Marcus,

 

1.

Point is, how do you *know* there's been no transmission? Where you in an
RF-tight room and switched off all your bluetooth devices, smart phones,
wireless door bells, wireless thermometers, RC car controls, wireless door
openers, remote controlled power outlet switches, wireless keyboards & mice,
wireless headphones... just to name the 2.4GHz ISM-band devices that pop
into my head right now.
There's not only WiFi in that band, really.

 

==> Nothing  , I am at palm oil plantations, Please see page 70

 

2.

What document? What details?

 

==> Attached technical analysis in 84 pages ;

 

https://mega.nz/#!YwplVCCT!Acbe00paHk3dLJuf04B5zSBifSw0-bHz5IciiNLgQwY

 

Regards

 

Srinivasan T



 

 

From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
Sent: Thursday, 11 February 2016 3:04 PM
To: Srinivasan T; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

 

Hi Srinivasan,

On 11.02.2016 05:11, Srinivasan T wrote:

Hi Marcus,

 

Thannks.

Spectrum density , that I have taken was in the are that there were no
transmission.

I have RF meter that to measure RF power , HackRF also detected unknown RF
that covered by Wi-Fi.

Point is, how do you *know* there's been no transmission? Where you in an
RF-tight room and switched off all your bluetooth devices, smart phones,
wireless door bells, wireless thermometers, RC car controls, wireless door
openers, remote controlled power outlet switches, wireless keyboards & mice,
wireless headphones... just to name the 2.4GHz ISM-band devices that pop
into my head right now.
There's not only WiFi in that band, really.




 

You can see while recording it. RF meter which I have also indicates the
radio sound is really unique. 

Another product, AirMagnet 2.4 GHz spectrum analyzer shows the same things.

 

Waterfall Pattern also dfferent. Many people not sure about 2.4 GHz.

in 84 pages document, I have checked all details .

What document? What details?
2.4GHz is, for almost everywhere of the world, an unlicensed band, and
there's practically no real limits on how the signals transmitted in there
look like.

Best regards,
Marcus

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

Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

2016-02-10 Thread Marcus Müller

Hi Srinivasan,

On 11.02.2016 05:11, Srinivasan T wrote:
>
> Hi Marcus,
>
>  
>
> Thannks.
>
> Spectrum density , that I have taken was in the are that there were no
> transmission.
>
> I have RF meter that to measure RF power , HackRF also detected
> unknown RF that covered by Wi-Fi.
>
Point is, how do you *know* there's been no transmission? Where you in
an RF-tight room and switched off all your bluetooth devices, smart
phones, wireless door bells, wireless thermometers, RC car controls,
wireless door openers, remote controlled power outlet switches, wireless
keyboards & mice, wireless headphones... just to name the 2.4GHz
ISM-band devices that pop into my head right now.
There's not only WiFi in that band, really.

>  
>
> You can see while recording it. RF meter which I have also indicates
> the radio sound is really unique.
>
> Another product, AirMagnet 2.4 GHz spectrum analyzer shows the same
> things.
>
>  
>
> Waterfall Pattern also dfferent. Many people not sure about 2.4 GHz.
>
> in 84 pages document, I have checked all details .
>
What document? What details?
2.4GHz is, for almost everywhere of the world, an unlicensed band, and
there's practically no real limits on how the signals transmitted in
there look like.

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

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

2016-02-10 Thread Zhihong Luo

For more information, the line that causes error is:

gr::uhd::usrp_source::sptr usrp_source =
gr::uhd::usrp_source::make(device_addr, uhd::stream_args_t("fc32"));

And if I delete the usrp_source::make line, there will be no error. But
even if I change it into the old style of make, the same error output
occurs. Therefore, the problem is about the new make function, which I used
from Revision 338cfae6. I just copied and pasted the three files of the
revision, then make and make install.

Thanks,
Zhihong

On Wed, Feb 10, 2016 at 10:21 PM, Zhihong Luo  wrote:

> Hi James,
>
> I modified the code, uninstalled then make and install again. But when I
> tried to generate the C API file (which can be generated before I did all
> these), it outputs errors:
>
> CMakeFiles/tags.dir/tags.cc.o: In function `_main(int, char**)':
> tags.cc:(.text+0x892): undefined reference to
> `gr::uhd::usrp_source::make(uhd::device_addr_t const&, uhd::stream_args_t
> const&, bool)'
> collect2: error: ld returned 1 exit status
> make[2]: *** [apps/tags] Error 1
> make[1]: *** [apps/CMakeFiles/tags.dir/all] Error 2
> make: *** [all] Error 2
>
> It has errors on usrp_source, which I just modified the code of. I checked
> the source files, they are the same as Revision 338cfae6. So where can my
> mistakes be? Thanks in advance.
>
> Zhihong
>
> On Wed, Feb 10, 2016 at 8:38 PM, James Humphries <
> james.humphr...@ettus.com> wrote:
>
>> You can uninstall in the build directory:
>>
>> sudo make uninstall
>>
>>
>>
>> On Wed, Feb 10, 2016 at 8:33 PM, Zhihong Luo  wrote:
>>
>>> Hi James,
>>>
>>> Actually, the commit was only a month ago, I checked my source code and
>>> it is different from the revised version. So just to make sure, what I need
>>> to do is to change the source files (usrp_source_impl.cc, usrp_source.h
>>> etc), then
>>>
>>> mkdir build  (under gnuradio/)
>>> cd build
>>> cmake ..
>>> make
>>> make test
>>> sudo make install
>>>
>>> Then the lib files will be overwritten? Or do I need to delete something
>>> before doing so?
>>>
>>> Thanks,
>>> Zhihong
>>>
>>> On Wed, Feb 10, 2016 at 7:43 PM, James Humphries <
>>> james.humphr...@ettus.com> wrote:
>>>
 Hi Zhihong,

 4ae7a6015ba719a4720f61cc6f3857de2ebda89f is the commit hash that refers
 to a specific commit on the GNU Radio repository.

 If you built GNU Radio recently (I believe this commit was last
 August), then you should be OK.

 -Trip

 On Wed, Feb 10, 2016 at 6:42 PM, Zhihong Luo  wrote:

> Hi Martin,
>
> What I want to do is to use the stream command to receive data, put it
> into the file, rest for like 2s, then start receiving again. I think I can
> do this by using multiple NUM SAMPLE AND DONE commands?
>
>  I don"t really understand the stop() here, I am using it because the
> manual seems to say so?  Previously, I simply called the issue-stream-cmd
> function before the flow graph start, but the file grew large very 
> rapidly,
> so I was thinking maybe the stop() is the right way to do it. Now I have 
> no
> idea how to call it.
>
> Sorry, but what is 4ae7a6015ba719a4720f61cc6f3857de2ebda89f ?
>
> Thanks a lot,
> Zhihong
> 2016年2月10日星期三，Martin Braun  写道：
>
>> Which version are you running?
>> 4ae7a6015ba719a4720f61cc6f3857de2ebda89f
>> should fix this issue.
>>
>> Also, is this really what you want to happen? If you just call
>> issue_stream_cmd() with a STOP command, it will stop, but all the data
>> will still flow through the graph, instead of getting flushed.
>> Especially as you are stopping and starting the flow graph.
>>
>> My guess is you don't really need stop() here.
>>
>> Cheers,
>> M
>>
>>
>> On 02/10/2016 03:07 PM, Zhihong Luo wrote:
>> > Hi All,
>> >
>> > In the manual, it says to use issue_stream_cmd:
>> >
>> > After starting the flow graph, the user should call stop()
>> > <
>> https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a0863bc16f7c84adf4cddf5d53124450e
>> >on
>> > this block, then issue any desired arbitrary stream_cmd_t structs
>> to the
>> > device
>> >
>> > Therefore, I tried to stop() then issue the stream command, but it
>> ran
>> > into segmentation fault. My code is:
>> >
>> > uhd::stream_cmd_t
>> > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>> >  size_t num_requested_samples= 1;
>> >  stream_cmd.num_samps = size_t(num_requested_samples);
>> >  stream_cmd.stream_now = true;
>> >  stream_cmd.time_spec = uhd::time_spec_t();
>> > ...
>> > std::cout << "starting flow graph" << std::endl;
>> > tb->start();
>> > usrp_source->stop();
>> > usrp_source->issue_stream_cmd (stream_cmd);
>> >
>> > Even if I delete the issue_str

Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

2016-02-10 Thread Srinivasan T

Hi Marcus,

 

Thannks.

Spectrum density , that I have taken was in the are that there were no
transmission.

I have RF meter that to measure RF power , HackRF also detected unknown RF
that covered by Wi-Fi.

 

You can see while recording it. RF meter which I have also indicates the
radio sound is really unique. 

Another product, AirMagnet 2.4 GHz spectrum analyzer shows the same things.

 

Waterfall Pattern also dfferent. Many people not sure about 2.4 GHz.

in 84 pages document, I have checked all details .

 

Is there anything that we can extract the information from the signal ( we
dont know the protocol ) ?

 

Regards

 

Srinivasan T

 

 

 

 

From: discuss-gnuradio-bounces+tsvs.lc=gmail@gnu.org
[mailto:discuss-gnuradio-bounces+tsvs.lc=gmail@gnu.org] On Behalf Of
Marcus Müller
Sent: Wednesday, 10 February 2016 10:29 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

 

Hi Srinivasan,

The gr-fosphor plot looks really OK. Why are you surprised that theres
spectrum usage on the 2.4GHz ISM band? Remember, that's the band where
everyone with a certified device can operate without asking for a license.

Your frequency line plot might indicate you're seeing overflows, which would
mean that your PC is too slow to keep up with processing the real time
samples that come in. It's really impossible to tell without knowing wheter
you saw overflow indicators on your console.

I don't really agree to your dBm measurements. The numbers you see on these
plots are not dBm , but dBFS, i.e. just the relation of signal magnitude to
1. That's not direct display of powers. 


Best regards,
Marcus

On 02/09/2016 11:47 AM, Srinivasan T wrote:

any info ?

 

From: Srinivasan T [mailto:tsvs...@gmail.com] 
Sent: Saturday, 6 February 2016 12:59 PM
To: 'discuss-gnuradio@gnu.org'
Subject: Re : Info on 2.4 GHz
Importance: High

 

Hi All

 

I am Srinivasan living in Singapore and have M.Sc. Comp.Sci. 

 

My self and few engineers have detected unknown RF at 2.4 GHz which has
different FFT pattern, waterfall image, Radio Sound.

The identification and classification of the signal is really difficult
process.

 

Below is the video reference :

 

· FFT at 2.4 GHz ( we can see sudden fluctuation and power in db is
really high ) 

https://sendvid.com/33f5hpkg

Detail : On this video, we can see peak hold in green color that leave a
trace something comes and go. Peak Hold line in green color shows external
signal interfered at 2.4 GHz 

 The fluctuation looks like external RF writing to it. 

 

· Spectrum Density of RF at 2.4 GHz  

http://sendvid.com/mu9m2jeg 

Details : I have taken this video at place where there was no devices
that operate at 2.4 GHz ( near plantations ).

We can see noise floor in blue color comes and go. 

This external interference cause Wi-Fi at 2.4 GHz to fluctuate and
sudden fluctuate at different power level will increase of SNR of Wi-Fi (
signal to noise ratio )  

 

· AirMagnet XT  

https://sendvid.com/tkq3xz0s   

Details : This software one of the best software available in the market
for detection  interference  Wi-Fi at 2.4 GHz with different options. 

We can see FFT picture at real time in leave suddenly max   hold
around -10 dBm.

 

· Wi-Fi Fluctuations at Siloam Hospital in Medan - Indonesia 

http://sendvid.com/2u2j34m7

I reported this issue to :

 

1. iDA- Singapore  ( Radio Spectrum monitor - Goverment agency )

2. MCMC - Singapore  ( Radio Spectrum monitor - Goverment agency )

3. Balmon - Indonesia ( Radio Spectrum monitor - Goverment agency )

4. Flight Operator because this unknown signal works on the flight as well.

 

They are not sure on how to pin point the source and other mechanism.

This signal works in 3 countries : Indonesia, Malaysia and Singapore.

The source may come from Satellite and possibility from SES-7 because this
satellite has S-band transponder.

 

Based on my detection : 

1. The RF covered by Wi-Fi signal. This can be seen while recording the
signal in wav format using SDR# and HackRF

Image below :

   cid:image006.jpg@01D14596.FE374120

2. The carrier frequency is 2.4 GHz 

3. Density value which I recorded :

1.   0.4187 mW / m2  ( 418.7   µW / m2 )   

2.   0.5520 mW / m2  ( 552.0   µW / m2 )   

3.   15.92  mW / m2   ( 15920  µW / m2 )

4. Recently i detected 1827 mW / m2 = 1.827 W / m2   =  1827000 uW / m2

 

Attached Radio Sound file :

https://mega.nz/#!8thAzY5D!4ZfOmHLSttQKtYQQlz6BBVtV_vqjrVsxSRiJVzdnRqs

 

Attached technical analysis in 84 pages ;

 

https://mega.nz/#!YwplVCCT!Acbe00paHk3dLJuf04B5zSBifSw0-bHz5IciiNLgQwY

 

I know that Radio Sound that can be analyst further.

I am looking for external expert - urgently to help on this. Looking forward
for your reply.

 

Regards

Re: [Discuss-gnuradio] GNU Radio Architecture and Implementation ?

2016-02-10 Thread West, Nathan

On Wed, Feb 10, 2016 at 7:47 PM, Abhinav Jadon 
wrote:

> Hi ,
> I was reading up about the architecture of GNU Radio. Its primarily an
> inheritance based architecture, the blocks that pass data to other block
> are actually implemented as subclass and superclass pair. Am I right about
> this?
> Also whats the need for the flowgraph to be a subclass of the top_block.
> Also, whats the difference between top_block and block ?
>
> Regards
>
>
Someone may come and explain this better, but at a super high level there
are the following important classes: basic_block, block, hier_block2,
top_block. They all inherit from basic_block which provides an API for
message handling, input and output signatures, name, and some other core
features. From basic_block you can get a hier_block2 or a block.
hier_block2 mostly provides an API for connecting blocks. top_block
inherits from hier_block2 and provides start and stop functionality which
creates buffers and runs other blocks in the flow (blocks that have been
->connect()'ed).

On the other fork of basic_block you have block, which provides an API for
providing information about how this block likes to do work (alignment,
relative_rate, history, noutput_items, ninput_items, forecast and more) and
also contains the block_detail. All signal processing blocks inherit from
block and are connected in a flowgraph through a top_block. Signal
processing blocks could just inherit from block if they need some special
cases, but most of the time you want a sync_block, sync_interpolator,
sync_decimator which inherit from block and reduce some of the API for you
based on different assumptions of relative_rate that you provide.

These are somewhat advanced questions though, and probably working through
the tutorials, making flowgraphs, and writing blocks while reading the
doxygen manual make some of this more apparent.

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

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

2016-02-10 Thread Zhihong Luo

Hi James,

I modified the code, uninstalled then make and install again. But when I
tried to generate the C API file (which can be generated before I did all
these), it outputs errors:

CMakeFiles/tags.dir/tags.cc.o: In function `_main(int, char**)':
tags.cc:(.text+0x892): undefined reference to
`gr::uhd::usrp_source::make(uhd::device_addr_t const&, uhd::stream_args_t
const&, bool)'
collect2: error: ld returned 1 exit status
make[2]: *** [apps/tags] Error 1
make[1]: *** [apps/CMakeFiles/tags.dir/all] Error 2
make: *** [all] Error 2

It has errors on usrp_source, which I just modified the code of. I checked
the source files, they are the same as Revision 338cfae6. So where can my
mistakes be? Thanks in advance.

Zhihong

On Wed, Feb 10, 2016 at 8:38 PM, James Humphries 
wrote:

> You can uninstall in the build directory:
>
> sudo make uninstall
>
>
>
> On Wed, Feb 10, 2016 at 8:33 PM, Zhihong Luo  wrote:
>
>> Hi James,
>>
>> Actually, the commit was only a month ago, I checked my source code and
>> it is different from the revised version. So just to make sure, what I need
>> to do is to change the source files (usrp_source_impl.cc, usrp_source.h
>> etc), then
>>
>> mkdir build  (under gnuradio/)
>> cd build
>> cmake ..
>> make
>> make test
>> sudo make install
>>
>> Then the lib files will be overwritten? Or do I need to delete something
>> before doing so?
>>
>> Thanks,
>> Zhihong
>>
>> On Wed, Feb 10, 2016 at 7:43 PM, James Humphries <
>> james.humphr...@ettus.com> wrote:
>>
>>> Hi Zhihong,
>>>
>>> 4ae7a6015ba719a4720f61cc6f3857de2ebda89f is the commit hash that refers
>>> to a specific commit on the GNU Radio repository.
>>>
>>> If you built GNU Radio recently (I believe this commit was last August),
>>> then you should be OK.
>>>
>>> -Trip
>>>
>>> On Wed, Feb 10, 2016 at 6:42 PM, Zhihong Luo  wrote:
>>>
 Hi Martin,

 What I want to do is to use the stream command to receive data, put it
 into the file, rest for like 2s, then start receiving again. I think I can
 do this by using multiple NUM SAMPLE AND DONE commands?

  I don"t really understand the stop() here, I am using it because the
 manual seems to say so?  Previously, I simply called the issue-stream-cmd
 function before the flow graph start, but the file grew large very rapidly,
 so I was thinking maybe the stop() is the right way to do it. Now I have no
 idea how to call it.

 Sorry, but what is 4ae7a6015ba719a4720f61cc6f3857de2ebda89f ?

 Thanks a lot,
 Zhihong
 2016年2月10日星期三，Martin Braun  写道：

> Which version are you running? 4ae7a6015ba719a4720f61cc6f3857de2ebda89f
> should fix this issue.
>
> Also, is this really what you want to happen? If you just call
> issue_stream_cmd() with a STOP command, it will stop, but all the data
> will still flow through the graph, instead of getting flushed.
> Especially as you are stopping and starting the flow graph.
>
> My guess is you don't really need stop() here.
>
> Cheers,
> M
>
>
> On 02/10/2016 03:07 PM, Zhihong Luo wrote:
> > Hi All,
> >
> > In the manual, it says to use issue_stream_cmd:
> >
> > After starting the flow graph, the user should call stop()
> > <
> https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a0863bc16f7c84adf4cddf5d53124450e
> >on
> > this block, then issue any desired arbitrary stream_cmd_t structs to
> the
> > device
> >
> > Therefore, I tried to stop() then issue the stream command, but it
> ran
> > into segmentation fault. My code is:
> >
> > uhd::stream_cmd_t
> > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
> >  size_t num_requested_samples= 1;
> >  stream_cmd.num_samps = size_t(num_requested_samples);
> >  stream_cmd.stream_now = true;
> >  stream_cmd.time_spec = uhd::time_spec_t();
> > ...
> > std::cout << "starting flow graph" << std::endl;
> > tb->start();
> > usrp_source->stop();
> > usrp_source->issue_stream_cmd (stream_cmd);
> >
> > Even if I delete the issue_stream_cmd line, there is still a
> > segmentation fault. Can someone point out where I made a mistake?
> Thanks.
> >
> > Zhihong Luo
> >
> >
> > ___
> > 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] Issue_stream_cmd, Segmentation Fault

2016-02-10 Thread James Humphries

You can uninstall in the build directory:

sudo make uninstall



On Wed, Feb 10, 2016 at 8:33 PM, Zhihong Luo  wrote:

> Hi James,
>
> Actually, the commit was only a month ago, I checked my source code and it
> is different from the revised version. So just to make sure, what I need to
> do is to change the source files (usrp_source_impl.cc, usrp_source.h etc),
> then
>
> mkdir build  (under gnuradio/)
> cd build
> cmake ..
> make
> make test
> sudo make install
>
> Then the lib files will be overwritten? Or do I need to delete something
> before doing so?
>
> Thanks,
> Zhihong
>
> On Wed, Feb 10, 2016 at 7:43 PM, James Humphries <
> james.humphr...@ettus.com> wrote:
>
>> Hi Zhihong,
>>
>> 4ae7a6015ba719a4720f61cc6f3857de2ebda89f is the commit hash that refers
>> to a specific commit on the GNU Radio repository.
>>
>> If you built GNU Radio recently (I believe this commit was last August),
>> then you should be OK.
>>
>> -Trip
>>
>> On Wed, Feb 10, 2016 at 6:42 PM, Zhihong Luo  wrote:
>>
>>> Hi Martin,
>>>
>>> What I want to do is to use the stream command to receive data, put it
>>> into the file, rest for like 2s, then start receiving again. I think I can
>>> do this by using multiple NUM SAMPLE AND DONE commands?
>>>
>>>  I don"t really understand the stop() here, I am using it because the
>>> manual seems to say so?  Previously, I simply called the issue-stream-cmd
>>> function before the flow graph start, but the file grew large very rapidly,
>>> so I was thinking maybe the stop() is the right way to do it. Now I have no
>>> idea how to call it.
>>>
>>> Sorry, but what is 4ae7a6015ba719a4720f61cc6f3857de2ebda89f ?
>>>
>>> Thanks a lot,
>>> Zhihong
>>> 2016年2月10日星期三，Martin Braun  写道：
>>>
 Which version are you running? 4ae7a6015ba719a4720f61cc6f3857de2ebda89f
 should fix this issue.

 Also, is this really what you want to happen? If you just call
 issue_stream_cmd() with a STOP command, it will stop, but all the data
 will still flow through the graph, instead of getting flushed.
 Especially as you are stopping and starting the flow graph.

 My guess is you don't really need stop() here.

 Cheers,
 M


 On 02/10/2016 03:07 PM, Zhihong Luo wrote:
 > Hi All,
 >
 > In the manual, it says to use issue_stream_cmd:
 >
 > After starting the flow graph, the user should call stop()
 > <
 https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a0863bc16f7c84adf4cddf5d53124450e
 >on
 > this block, then issue any desired arbitrary stream_cmd_t structs to
 the
 > device
 >
 > Therefore, I tried to stop() then issue the stream command, but it ran
 > into segmentation fault. My code is:
 >
 > uhd::stream_cmd_t
 > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
 >  size_t num_requested_samples= 1;
 >  stream_cmd.num_samps = size_t(num_requested_samples);
 >  stream_cmd.stream_now = true;
 >  stream_cmd.time_spec = uhd::time_spec_t();
 > ...
 > std::cout << "starting flow graph" << std::endl;
 > tb->start();
 > usrp_source->stop();
 > usrp_source->issue_stream_cmd (stream_cmd);
 >
 > Even if I delete the issue_stream_cmd line, there is still a
 > segmentation fault. Can someone point out where I made a mistake?
 Thanks.
 >
 > Zhihong Luo
 >
 >
 > ___
 > 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] Issue_stream_cmd, Segmentation Fault

2016-02-10 Thread Zhihong Luo

Hi James,

Actually, the commit was only a month ago, I checked my source code and it
is different from the revised version. So just to make sure, what I need to
do is to change the source files (usrp_source_impl.cc, usrp_source.h etc),
then

mkdir build  (under gnuradio/)
cd build
cmake ..
make
make test
sudo make install

Then the lib files will be overwritten? Or do I need to delete something
before doing so?

Thanks,
Zhihong

On Wed, Feb 10, 2016 at 7:43 PM, James Humphries 
wrote:

> Hi Zhihong,
>
> 4ae7a6015ba719a4720f61cc6f3857de2ebda89f is the commit hash that refers to
> a specific commit on the GNU Radio repository.
>
> If you built GNU Radio recently (I believe this commit was last August),
> then you should be OK.
>
> -Trip
>
> On Wed, Feb 10, 2016 at 6:42 PM, Zhihong Luo  wrote:
>
>> Hi Martin,
>>
>> What I want to do is to use the stream command to receive data, put it
>> into the file, rest for like 2s, then start receiving again. I think I can
>> do this by using multiple NUM SAMPLE AND DONE commands?
>>
>>  I don"t really understand the stop() here, I am using it because the
>> manual seems to say so?  Previously, I simply called the issue-stream-cmd
>> function before the flow graph start, but the file grew large very rapidly,
>> so I was thinking maybe the stop() is the right way to do it. Now I have no
>> idea how to call it.
>>
>> Sorry, but what is 4ae7a6015ba719a4720f61cc6f3857de2ebda89f ?
>>
>> Thanks a lot,
>> Zhihong
>> 2016年2月10日星期三，Martin Braun  写道：
>>
>>> Which version are you running? 4ae7a6015ba719a4720f61cc6f3857de2ebda89f
>>> should fix this issue.
>>>
>>> Also, is this really what you want to happen? If you just call
>>> issue_stream_cmd() with a STOP command, it will stop, but all the data
>>> will still flow through the graph, instead of getting flushed.
>>> Especially as you are stopping and starting the flow graph.
>>>
>>> My guess is you don't really need stop() here.
>>>
>>> Cheers,
>>> M
>>>
>>>
>>> On 02/10/2016 03:07 PM, Zhihong Luo wrote:
>>> > Hi All,
>>> >
>>> > In the manual, it says to use issue_stream_cmd:
>>> >
>>> > After starting the flow graph, the user should call stop()
>>> > <
>>> https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a0863bc16f7c84adf4cddf5d53124450e
>>> >on
>>> > this block, then issue any desired arbitrary stream_cmd_t structs to
>>> the
>>> > device
>>> >
>>> > Therefore, I tried to stop() then issue the stream command, but it ran
>>> > into segmentation fault. My code is:
>>> >
>>> > uhd::stream_cmd_t
>>> > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>>> >  size_t num_requested_samples= 1;
>>> >  stream_cmd.num_samps = size_t(num_requested_samples);
>>> >  stream_cmd.stream_now = true;
>>> >  stream_cmd.time_spec = uhd::time_spec_t();
>>> > ...
>>> > std::cout << "starting flow graph" << std::endl;
>>> > tb->start();
>>> > usrp_source->stop();
>>> > usrp_source->issue_stream_cmd (stream_cmd);
>>> >
>>> > Even if I delete the issue_stream_cmd line, there is still a
>>> > segmentation fault. Can someone point out where I made a mistake?
>>> Thanks.
>>> >
>>> > Zhihong Luo
>>> >
>>> >
>>> > ___
>>> > 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] Tagged stream align duplicates tags

2016-02-10 Thread Jared Dulmage

I have also run into this issue.  Since no one has yet created the issue on 
gnuradio.org I will do so today.  The solution is to add a 

set_tag_propagation_policy(TPP_DONT);

in the constructor.  I've already tested this and it works.

Jared.
--
Jared Dulmage
Engineering Specialist
Digital Comm. and Implementation Dept.
Aerospace Corporation
310-336-3140

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

[Discuss-gnuradio] GNU Radio Architecture and Implementation ?

2016-02-10 Thread Abhinav Jadon

Hi ,
I was reading up about the architecture of GNU Radio. Its primarily an
inheritance based architecture, the blocks that pass data to other block
are actually implemented as subclass and superclass pair. Am I right about
this?
Also whats the need for the flowgraph to be a subclass of the top_block.
Also, whats the difference between top_block and block ?

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

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

2016-02-10 Thread James Humphries

Hi Zhihong,

4ae7a6015ba719a4720f61cc6f3857de2ebda89f is the commit hash that refers to
a specific commit on the GNU Radio repository.

If you built GNU Radio recently (I believe this commit was last August),
then you should be OK.

-Trip

On Wed, Feb 10, 2016 at 6:42 PM, Zhihong Luo  wrote:

> Hi Martin,
>
> What I want to do is to use the stream command to receive data, put it
> into the file, rest for like 2s, then start receiving again. I think I can
> do this by using multiple NUM SAMPLE AND DONE commands?
>
>  I don"t really understand the stop() here, I am using it because the
> manual seems to say so?  Previously, I simply called the issue-stream-cmd
> function before the flow graph start, but the file grew large very rapidly,
> so I was thinking maybe the stop() is the right way to do it. Now I have no
> idea how to call it.
>
> Sorry, but what is 4ae7a6015ba719a4720f61cc6f3857de2ebda89f ?
>
> Thanks a lot,
> Zhihong
> 2016年2月10日星期三，Martin Braun  写道：
>
>> Which version are you running? 4ae7a6015ba719a4720f61cc6f3857de2ebda89f
>> should fix this issue.
>>
>> Also, is this really what you want to happen? If you just call
>> issue_stream_cmd() with a STOP command, it will stop, but all the data
>> will still flow through the graph, instead of getting flushed.
>> Especially as you are stopping and starting the flow graph.
>>
>> My guess is you don't really need stop() here.
>>
>> Cheers,
>> M
>>
>>
>> On 02/10/2016 03:07 PM, Zhihong Luo wrote:
>> > Hi All,
>> >
>> > In the manual, it says to use issue_stream_cmd:
>> >
>> > After starting the flow graph, the user should call stop()
>> > <
>> https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a0863bc16f7c84adf4cddf5d53124450e
>> >on
>> > this block, then issue any desired arbitrary stream_cmd_t structs to the
>> > device
>> >
>> > Therefore, I tried to stop() then issue the stream command, but it ran
>> > into segmentation fault. My code is:
>> >
>> > uhd::stream_cmd_t
>> > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>> >  size_t num_requested_samples= 1;
>> >  stream_cmd.num_samps = size_t(num_requested_samples);
>> >  stream_cmd.stream_now = true;
>> >  stream_cmd.time_spec = uhd::time_spec_t();
>> > ...
>> > std::cout << "starting flow graph" << std::endl;
>> > tb->start();
>> > usrp_source->stop();
>> > usrp_source->issue_stream_cmd (stream_cmd);
>> >
>> > Even if I delete the issue_stream_cmd line, there is still a
>> > segmentation fault. Can someone point out where I made a mistake?
>> Thanks.
>> >
>> > Zhihong Luo
>> >
>> >
>> > ___
>> > 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] gr-ieee 802.11 Wifi Transceiver Issue

2016-02-10 Thread Bastian Bloessl

Hi

> On 10 Feb 2016, at 15:13, Abhinav Jadon  wrote:
> Next I replaced the loopback with a uhd source and sink and connected the RF 
> frontends using a SMA cable. It fails to give me any packet (the wireshark 
> connector). I tried playing with the value of rx_gain and tx_gain. I also 
> tried playing with the value of the the correlation threshold. 
> I then chose to debug using the data flow. The data in the flowgraph flows 
> until the Decode MAC block where it gets dropped with checksum wrong message.
> 

Your debugging sounds already pretty good. Some more stuff you could try

- assert that there are no overruns (‘O’s or ‘D’ on the console)
- check that frame detection is working (there are no frames detected when the 
transmitter is turned off)
- test with antennas
- assert that you connected the correct antenna ports (RX and TX use a 
different ports by default)
- set a different LO offset
- use the LMS equaliser
- try a different sample rate / bandwidth
- check if the signal field is decoded correctly (log or debug option)

Best,
Bastian


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

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

2016-02-10 Thread Zhihong Luo

Hi Martin,

What I want to do is to use the stream command to receive data, put it into
the file, rest for like 2s, then start receiving again. I think I can do
this by using multiple NUM SAMPLE AND DONE commands?

 I don"t really understand the stop() here, I am using it because the
manual seems to say so?  Previously, I simply called the issue-stream-cmd
function before the flow graph start, but the file grew large very rapidly,
so I was thinking maybe the stop() is the right way to do it. Now I have no
idea how to call it.

Sorry, but what is 4ae7a6015ba719a4720f61cc6f3857de2ebda89f ?

Thanks a lot,
Zhihong
2016年2月10日星期三，Martin Braun  写道：

> Which version are you running? 4ae7a6015ba719a4720f61cc6f3857de2ebda89f
> should fix this issue.
>
> Also, is this really what you want to happen? If you just call
> issue_stream_cmd() with a STOP command, it will stop, but all the data
> will still flow through the graph, instead of getting flushed.
> Especially as you are stopping and starting the flow graph.
>
> My guess is you don't really need stop() here.
>
> Cheers,
> M
>
>
> On 02/10/2016 03:07 PM, Zhihong Luo wrote:
> > Hi All,
> >
> > In the manual, it says to use issue_stream_cmd:
> >
> > After starting the flow graph, the user should call stop()
> > <
> https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a0863bc16f7c84adf4cddf5d53124450e
> >on
> > this block, then issue any desired arbitrary stream_cmd_t structs to the
> > device
> >
> > Therefore, I tried to stop() then issue the stream command, but it ran
> > into segmentation fault. My code is:
> >
> > uhd::stream_cmd_t
> > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
> >  size_t num_requested_samples= 1;
> >  stream_cmd.num_samps = size_t(num_requested_samples);
> >  stream_cmd.stream_now = true;
> >  stream_cmd.time_spec = uhd::time_spec_t();
> > ...
> > std::cout << "starting flow graph" << std::endl;
> > tb->start();
> > usrp_source->stop();
> > usrp_source->issue_stream_cmd (stream_cmd);
> >
> > Even if I delete the issue_stream_cmd line, there is still a
> > segmentation fault. Can someone point out where I made a mistake? Thanks.
> >
> > Zhihong Luo
> >
> >
> > ___
> > 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] Issue_stream_cmd, Segmentation Fault

2016-02-10 Thread Martin Braun

Which version are you running? 4ae7a6015ba719a4720f61cc6f3857de2ebda89f
should fix this issue.

Also, is this really what you want to happen? If you just call
issue_stream_cmd() with a STOP command, it will stop, but all the data
will still flow through the graph, instead of getting flushed.
Especially as you are stopping and starting the flow graph.

My guess is you don't really need stop() here.

Cheers,
M


On 02/10/2016 03:07 PM, Zhihong Luo wrote:
> Hi All,
> 
> In the manual, it says to use issue_stream_cmd:
> 
> After starting the flow graph, the user should call stop()
> on
> this block, then issue any desired arbitrary stream_cmd_t structs to the
> device
> 
> Therefore, I tried to stop() then issue the stream command, but it ran
> into segmentation fault. My code is:
>  
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>  size_t num_requested_samples= 1;
>  stream_cmd.num_samps = size_t(num_requested_samples);
>  stream_cmd.stream_now = true;
>  stream_cmd.time_spec = uhd::time_spec_t();
> ...
> std::cout << "starting flow graph" << std::endl;
> tb->start();
> usrp_source->stop();
> usrp_source->issue_stream_cmd (stream_cmd);
> 
> Even if I delete the issue_stream_cmd line, there is still a
> segmentation fault. Can someone point out where I made a mistake? Thanks.
> 
> Zhihong Luo
> 
> 
> ___
> 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] Cant receive .wav file correctly

2016-02-10 Thread Martin Braun

Your DPSK demod takes some time before loops are locked etc. I assume
that's what you're seeing. Try bypassing both PSK blocks and see if the
packetizers are working fine.

Cheers,
Martin

On 02/09/2016 06:58 PM, Haaris wrote:
> Hi all,
> Thanks for the reply martin.
> The dpsk mod and demod work alright with the packet encoder and decoder
> that i am currently using.
> This flow graph recovers a text file somewhat alright. One problem is
> that even though i have selected overwrite data in file sink, it still
> appends the recovered data again and again. The second is that every
> time first 412 characters of the data are missing of the start
> paragraph. As repeat is turned on in file source, when the data is
> repeated there are no characters missing and all the data is
> successfully recovered after the first time. e.g.
> 
> data = x x x x
>   x x x x
>   x x x x
> 
> recovered data with repeat on = x x(412 characters missing)
>x x x x
> 
>x x x x
>x x x x
>x x x x
> 
>x x x x
>x x x x
>x x x x  
> 
> So what happens with the wav file sink and source, why does file sink
> and source miss the starting 412 characters everytime when recovering
> data and why does the file sink does'nt overwrite the data?
> 
> Thanks in advance
> 
> 
> ___
> 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] gr-ieee 802.11 Wifi Transceiver Issue

2016-02-10 Thread Abhinav Jadon

Hi ,

I was working on the Wifi Transceiver Flowgraph. I created a loopback in
the flowgraph itself to be sure that atleast the transceiver works in
theory. It did work like magic.
Next I replaced the loopback with a uhd source and sink and connected the
RF frontends using a SMA cable. It fails to give me any packet (the
wireshark connector). I tried playing with the value of rx_gain and
tx_gain. I also tried playing with the value of the the correlation
threshold.
I then chose to debug using the data flow. The data in the flowgraph flows
until the Decode MAC block where it gets dropped with checksum wrong
message.

Can you please provide your feedback on this ?

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

[Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

2016-02-10 Thread Zhihong Luo

Hi All,

In the manual, it says to use issue_stream_cmd:

After starting the flow graph, the user should call stop()
on
this block, then issue any desired arbitrary stream_cmd_t structs to the
device

Therefore, I tried to stop() then issue the stream command, but it ran into
segmentation fault. My code is:

uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
 size_t num_requested_samples= 1;
 stream_cmd.num_samps = size_t(num_requested_samples);
 stream_cmd.stream_now = true;
 stream_cmd.time_spec = uhd::time_spec_t();
...
std::cout << "starting flow graph" << std::endl;
tb->start();
usrp_source->stop();
usrp_source->issue_stream_cmd (stream_cmd);

Even if I delete the issue_stream_cmd line, there is still a segmentation
fault. Can someone point out where I made a mistake? Thanks.

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

Re: [Discuss-gnuradio] Pybombs Question

2016-02-10 Thread Richard Bell

Ah, didn't notice it there.

Thanks,
Rich

On Wed, Feb 10, 2016 at 1:27 PM, Seth Hitefield  wrote:

> The environment variable file (setup_env) is automatically generated when
> you create a new prefix. You simply need to source it as before in .bashrc
>
> -- Seth
>
>
> On 02/10/2016 04:23 PM, Richard Bell wrote:
>
> What is the new way of setting up environment variables, I'm not able to
> find information on that.
>
> The old way was to run './pybombs env' and source this auto-generated file
> from .bashrc file.
>
> Rich
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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] Pybombs Question

2016-02-10 Thread Seth Hitefield

The environment variable file (setup_env) is automatically generated 
when you create a new prefix. You simply need to source it as before in 
.bashrc


-- Seth


On 02/10/2016 04:23 PM, Richard Bell wrote:
What is the new way of setting up environment variables, I'm not able 
to find information on that.


The old way was to run './pybombs env' and source this auto-generated 
file from .bashrc file.


Rich


___
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] Pybombs Question

2016-02-10 Thread Richard Bell

What is the new way of setting up environment variables, I'm not able to
find information on that.

The old way was to run './pybombs env' and source this auto-generated file
from .bashrc file.

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

Re: [Discuss-gnuradio] Building ControlPort support into OOT module

2016-02-10 Thread Jacob Gilbert

Tom -

So as it turned out, I had the rpcbasic_register_set<> value types
mismatched (signed vs unsigned) and that error was hidden within a huge
mess of errors that appeared to be "could not find rpcbasic_register_set"
errors. Sorry for the confusion.

Thank you for the #include. That builds with GR_CTRLPORT set. Are there any
recommendations for what the "suggestion" pmt's should be for string-type
values?

Thanks


On Wed, Feb 10, 2016 at 11:42 AM, Tom Rondeau  wrote:

> On Wed, Feb 10, 2016 at 11:37 AM, Jacob Gilbert  > wrote:
>
>> I'm having some trouble adding ControlPort hooks to an OOT module. Is
>> there a guide on this I am missing? I followed the ControlPort manual page
>> including the #ifdef statements, however GR_CTRLPORT is not set and the
>> controlport code never gets built.
>>
>
>
> For this, use:
>
> #include 
>
> That file defines GR_CTRLPORT (if it's been enabled in GNU Radio).
>
>
>
>> If I force the code to be built, the build fails as none of the
>> controlport stuff is included. There appears to be some CMake or include
>> statements I am missing. I tried to modify the top-level/lib/swig cmake
>> files to emulate what in-tree modules have done but to no avail.
>>
>> ControlPort and thrift are definitely built into the GR installation and
>> works just fine. Any pointers are appreciated. GR is release 3.9.2
>>
>> Thanks, Jacob
>>
>
>
> Can you post the error you're seeing? All ControlPort functionality is
> built into gnuradio-runtime, which you should be linking against by default
> in any gr_modtool project. But yeah, the actual error will help narrow this
> down to what the real problem is.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building ControlPort support into OOT module

2016-02-10 Thread Tom Rondeau

On Wed, Feb 10, 2016 at 11:37 AM, Jacob Gilbert 
wrote:

> I'm having some trouble adding ControlPort hooks to an OOT module. Is
> there a guide on this I am missing? I followed the ControlPort manual page
> including the #ifdef statements, however GR_CTRLPORT is not set and the
> controlport code never gets built.
>

For this, use:

#include 

That file defines GR_CTRLPORT (if it's been enabled in GNU Radio).

> If I force the code to be built, the build fails as none of the
> controlport stuff is included. There appears to be some CMake or include
> statements I am missing. I tried to modify the top-level/lib/swig cmake
> files to emulate what in-tree modules have done but to no avail.
>
> ControlPort and thrift are definitely built into the GR installation and
> works just fine. Any pointers are appreciated. GR is release 3.9.2
>
> Thanks, Jacob
>

Can you post the error you're seeing? All ControlPort functionality is
built into gnuradio-runtime, which you should be linking against by default
in any gr_modtool project. But yeah, the actual error will help narrow this
down to what the real problem is.

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

[Discuss-gnuradio] Questions about transmit and receive with USRP N210 & GNU 3.6.5 use SBX dboard

2016-02-10 Thread kerry

Hi,all:
I am trying to transmit something and receive it back using the same USRP
N210 device.
However it fails, or I did not do it correctly.

I run the receiver first use below command:

sudo ./benchmark_rx.py -f 2.45M

Then I run the transmitter use below command:

sudo ./benchmark_tx.py -f 2.45G 

The transmitter back  "."

But the receiver gives me:
TIMEOUT

I changed the frequency also did not work.

What can cause this?
Is this a hardware problem?
I use SBX dboard. I think it can both receive and transmit at the same time.
Or maybe my incorrect operation？

Thanks，
Ke




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Questions-about-transmit-and-receive-with-USRP-N210-GNU-3-6-5-use-SBX-dboard-tp58121.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

[Discuss-gnuradio] Building ControlPort support into OOT module

2016-02-10 Thread Jacob Gilbert

I'm having some trouble adding ControlPort hooks to an OOT module. Is there
a guide on this I am missing? I followed the ControlPort manual page
including the #ifdef statements, however GR_CTRLPORT is not set and the
controlport code never gets built.

If I force the code to be built, the build fails as none of the controlport
stuff is included. There appears to be some CMake or include statements I
am missing. I tried to modify the top-level/lib/swig cmake files to emulate
what in-tree modules have done but to no avail.

ControlPort and thrift are definitely built into the GR installation and
works just fine. Any pointers are appreciated. GR is release 3.9.2

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

Re: [Discuss-gnuradio] Using static variables in work function of an OOT module.

2016-02-10 Thread Marcus Müller

As said, we don't see any connection between your usage of static
variables and that error. Sorry we can't help you with that.

Best regards,
Marcus

On 02/10/2016 03:41 PM, sagar wrote:
> Hi,
>
>  Thanks Marcus and Sylvain it works with class variables. But it  
> still difficult to figure out why gnu radio threw such error and it's  
> one of the most common errors that people come across in gnu radio.
>
> Best Regards,
> Sagar
>
> Quoting "Marcus Müller-3 [via GnuRadio]" <[hidden email]
> >:
>
> > Hi Saga,
> >
> > The line that goes wrong is this:
> >> self.create_tags_strend_ff_0 = create_tags.strend_ff(-30.0)
> > So this means that the constructor isn't wrapped in Python. I don't
> know
> > in which way that could be related to you doing somethin in work(); you
> > really shouldn't be using static variables if you can help it! In your
> > case, you really should not use it; the way you use them, they should
> > simply be class members.
> >
> > I don't actually think this has something to do with the static
> > variables usage, though; the constructor being undefined might mean
> that
> > something else went wrong.
> >
> > Best regards,
> > Marcus
> >
> > On 02/09/2016 03:38 PM, sagar wrote:
> >> Hi Marcus,
> >>
> >> Thank you for quick response. I have posted my error incompletely.
> I am
> >> actually getting the below error
> >>
> >> File "/home/user1/home/user1/gnuradio/tutorials/work/top_block.py",
> line
> >> 275, in 
> >> tb = top_block()
> >> File "/home/user1/home/user1/gnuradio/tutorials/work/top_block.py",
> line
> >> 183, in __init__
> >> self.create_tags_strend_ff_0 = create_tags.strend_ff(-30.0)
> >> AttributeError: 'module' object has no attribute 'strend_ff'
> >>
> >> I get this error only when I try to access static variables inside
> work
> >> function. otherwise the GRC won't show any such errors
> >>
> >> Do I have to use static variables differently then usual in gnu
> radio c++
> >> programs? If so, any pointers to study those concepts will be
> really helpful
> >>
> >>
> >> Thanks again.
> >>
> >> Best Regards,
> >> Saga
> >>
> >>
> >>
> >> --
> >> View this message in context:  
> >>
> http://gnuradio.4.n7.nabble.com/Using-static-variables-in-work-function-of-an-OOT-module-tp58094p58105.html
> >> Sent from the GnuRadio mailing list archive at Nabble.com.
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> [hidden email] 
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > [hidden email] 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> >
> > ___
> > If you reply to this email, your message will be added to the  
> > discussion below:
> >
> http://gnuradio.4.n7.nabble.com/Using-static-variables-in-work-function-of-an-OOT-module-tp58094p58107.html
> >
> > To unsubscribe from Using static variables in work function of an  
> > OOT module., visit  
> >
> 
> View this message in context: Re: Using static variables in work
> function of an OOT module.
> 
> 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

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

Re: [Discuss-gnuradio] Using static variables in work function of an OOT module.

2016-02-10 Thread sagar

Hi,

 Thanks Marcus and Sylvain it works with class variables. But it  
still difficult to figure out why gnu radio threw such error and it's  
one of the most common errors that people come across in gnu radio.

Best Regards,
Sagar

Quoting "Marcus Müller-3 [via GnuRadio]" :

> Hi Saga,
>
> The line that goes wrong is this:
>> self.create_tags_strend_ff_0 = create_tags.strend_ff(-30.0)
> So this means that the constructor isn't wrapped in Python. I don't know
> in which way that could be related to you doing somethin in work(); you
> really shouldn't be using static variables if you can help it! In your
> case, you really should not use it; the way you use them, they should
> simply be class members.
>
> I don't actually think this has something to do with the static
> variables usage, though; the constructor being undefined might mean that
> something else went wrong.
>
> Best regards,
> Marcus
>
> On 02/09/2016 03:38 PM, sagar wrote:
>> Hi Marcus,
>>
>> Thank you for quick response. I have posted my error incompletely. I am
>> actually getting the below error
>>
>> File "/home/user1/home/user1/gnuradio/tutorials/work/top_block.py", line
>> 275, in 
>> tb = top_block()
>> File "/home/user1/home/user1/gnuradio/tutorials/work/top_block.py", line
>> 183, in __init__
>> self.create_tags_strend_ff_0 = create_tags.strend_ff(-30.0)
>> AttributeError: 'module' object has no attribute 'strend_ff'
>>
>> I get this error only when I try to access static variables inside work
>> function. otherwise the GRC won't show any such errors
>>
>> Do I have to use static variables differently then usual in gnu radio c++
>> programs? If so, any pointers to study those concepts will be really helpful
>>
>>
>> Thanks again.
>>
>> Best Regards,
>> Saga
>>
>>
>>
>> --
>> View this message in context:  
>> http://gnuradio.4.n7.nabble.com/Using-static-variables-in-work-function-of-an-OOT-module-tp58094p58105.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
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> If you reply to this email, your message will be added to the  
> discussion below:
> http://gnuradio.4.n7.nabble.com/Using-static-variables-in-work-function-of-an-OOT-module-tp58094p58107.html
>
> To unsubscribe from Using static variables in work function of an  
> OOT module., visit  
> http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=58094&code=c2FnYXIua2FybXVyLm5hcmFzaW1oYS5yZWRkeUB0dWhoLmRlfDU4MDk0fC01MTc5MTc0Njg=






--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Using-static-variables-in-work-function-of-an-OOT-module-tp58094p58118.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] comedi in grc

2016-02-10 Thread Tom Rondeau

On Wed, Feb 10, 2016 at 9:05 AM, Yann Le Coq  wrote:

> Hello,
>
> In the process of writing the xml files for gr-comedi in grc and testing
> the result, I believe I am getting in an gr-comedi issue.
>
> The only comedi board I have access to is a USB-DUX Sigma, which outputs
> ADC data in the comedi type "lsampl_t" (32 bits per sample). The gr-comedi
> module, however, is hard coded for the comedi type "sampl_t" (16 bits per
> sample only).
>
> The only way I see to make this work for the USB-DUX Sigma (or any other
> >16bits ADC equipped board) is to modify the gr-comedi module C source
> itself, so as to accomodate 32 bits ADC devices.
>
> If I were to do this, I would, however, be tempted to change the output
> type entirely. The way it is done now, the comedi-device is expected to
> return "sampl_t" type raw data (unsigned 16 bits), which are then shifted
> down by -32767 and the resulting "signed and hopefully zero-centered" data
> is output as a short. There might be a good reason for that, but it seems
> more likely to be a quick hack, that has the drawback of making the whole
> module interface too device-dependant, IMHO.
>
> The comedilib standard way would rather be to use the comedilib function
> "comedi_to_phys()", which takes raw data and makes it a float that actually
> represents a physical value (a voltage for example) based on the
> channel/board configuration (unipolar/bipolar, ADC range, etc.). This
> function helps a lot providing device-independence and I don't see good
> reason why gnu-radio shouldn't be using it. In fact, I don't see why one
> would want to have access to the raw data itself from gnuradio, especially
> if it means changing the output type depending on the device being used...
> Getting a physically meaningful float output seems to make ways more sense.
>
> Doing this modification would, however, break backward compatibility with
> pre-existing gr-comedi-using top_blocks, so I am a bit hesitant and would
> like some feedback before investing the time that is necessary to make this
> change.
>
> Best regards,
>
> -Yann


Yann,
Great work so far, and sounds like it might be a useful addition to
gr-comedi. We don't have many users of that library, but I've spoken to a
number of labs who are interested. Providing a better solution would be
great.

Instead of breaking the current block, what I would recommend is adding a
second block to support your input/output requirements. For the input,
perhaps you could make the number of bits settable by the user (just 16 or
32, probably) and the output type float. Then wrap this up in the GRC XML
file for your needs. We'll keep the other block there for backwards
compatibility.

Thanks!
Tom




> Le 01/02/2016 18:19, Marcus Müller a écrit :
>
>> Hello Yann,
>>
>> no, you're not missing something; I don't remember there ever being GRC
>> XML files for gr-comedi, but if there where pre-3.7, they might have
>> gone away during the restructuration for 3.7; and, as there seemed to be
>> very little interest in getting gr-comedi to work from within GRC
>>
>> At any rate, since the sink and source have no own method and their
>> ctor/make functions only take sample rate and device address string as
>> arguments, copy&pasting together a valid XML file should be done very
>> quickly. However, I (used to think that I) don't know anyone who has
>> uses comed to talk to a data aquisition or signal generation device –
>> which would be useful for testing.
>>
>> So, would you be willing to contribute such XML?
>>
>> Best regards,
>> Marcus
>>
>> On 01.02.2016 18:00, Yann Le Coq wrote:
>>
>>> Hello,
>>>
>>> Unless I missed a point in compilation from source, there doesn't seem
>>> to be a grc blocks for the comedi driver gnuradio interface in a
>>> standard installation (origin/maint commit
>>> 11973c64437683cc99c48eae9eb4db8234f1ac42). Indeed, in the source code,
>>> there is no /grc sub-folder in the gr-comedi folder to define the .xml
>>> files.
>>>
>>> Am I missing something, or is there a place somewhere where this can
>>> be found ?
>>>
>>> Thank you for your help.
>>>
>>> -Yann
>>>
>>>
>>>
>>> ___
>>> 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] Re : Info on 2.4 GHz

2016-02-10 Thread Marcus Müller

Hi Srinivasan,

The gr-fosphor plot looks really OK. Why are you surprised that theres
spectrum usage on the 2.4GHz ISM band? Remember, that's the band where
everyone with a certified device can operate without asking for a license.

Your frequency line plot might indicate you're seeing overflows, which
would mean that your PC is too slow to keep up with processing the real
time samples that come in. It's really impossible to tell without
knowing wheter you saw overflow indicators on your console.

I don't really agree to your dBm measurements. The numbers you see on
these plots are not dBm , but dBFS, i.e. just the relation of signal
magnitude to 1. That's not direct display of powers.


Best regards,
Marcus

On 02/09/2016 11:47 AM, Srinivasan T wrote:
>
> any info ?
>
>  
>
> *From:*Srinivasan T [mailto:tsvs...@gmail.com]
> *Sent:* Saturday, 6 February 2016 12:59 PM
> *To:* 'discuss-gnuradio@gnu.org'
> *Subject:* Re : Info on 2.4 GHz
> *Importance:* High
>
>  
>
> Hi All
>
>  
>
> I am Srinivasan living in Singapore and have M.Sc. Comp.Sci.
>
>  
>
> My self and few engineers have detected unknown RF at 2.4 GHz which
> has different FFT pattern, waterfall image, Radio Sound.
>
> The identification and classification of the signal is really
> difficult process.
>
>  
>
> Below is the video reference :
>
>  
>
> · *FFT at 2.4 GHz ( we can see sudden fluctuation and power in
> db is really high ) *
>
> https://sendvid.com/33f5hpkg
>
> Detail : On this video, we can see peak hold in green color that
> leave a trace something comes and go. Peak Hold line in green color
> shows external signal interfered at 2.4 GHz
>
>  The fluctuation looks like external RF writing to it.
>
>  
>
> · *Spectrum Density of RF at 2.4 GHz  *
>
> http://sendvid.com/mu9m2jeg
>
> Details : I have taken this video at place where there was no
> devices that operate at 2.4 GHz ( near plantations ).
>
> We can see noise floor in blue color comes and go.
>
> This external interference cause Wi-Fi at 2.4 GHz to fluctuate and
> sudden fluctuate at different power level will increase of SNR of
> Wi-Fi ( signal to noise ratio ) 
>
>  
>
> · *AirMagnet XT  *
>
> https://sendvid.com/tkq3xz0s  
>
> Details : This software one of the best software available in the
> market for detection  interference  Wi-Fi at 2.4 GHz with different
> options.
>
> We can see FFT picture at real time in leave suddenly max  
> hold around -10 dBm.
>
>  
>
> · *Wi-Fi Fluctuations at Siloam Hospital in Medan - Indonesia *
>
> http://sendvid.com/2u2j34m7
>
> I reported this issue to :
>
>  
>
> 1. iDA- Singapore  ( Radio Spectrum monitor - Goverment agency )
>
> 2. MCMC - Singapore  ( Radio Spectrum monitor - Goverment agency )
>
> 3. Balmon - Indonesia ( Radio Spectrum monitor - Goverment agency )
>
> *4. Flight Operator because this unknown signal works on the flight as
> well.*
>
>  
>
> They are not sure on how to pin point the source and other mechanism.
>
> This signal works in 3 countries : Indonesia, Malaysia and Singapore.
>
> The source may come from Satellite and possibility from SES-7 because
> this satellite has S-band transponder.
>
>  
>
> Based on my detection :
>
> 1. The RF covered by Wi-Fi signal. This can be seen while recording
> the signal in wav format using SDR# and HackRF
>
> Image below :
>
>cid:image006.jpg@01D14596.FE374120
>
> 2. The carrier frequency is 2.4 GHz
>
> 3. Density value which I recorded :
>
> 1.   0.4187 mW / m2  ( 418.7   µW / m2 )  
>
> 2.   0.5520 mW / m2  ( 552.0   µW / m2 )  
>
> 3.   15.92  mW / m2   ( 15920  µW / m2 )
>
> 4. Recently i detected *1827**mW / m^2 = 1.827 W / m^2 *   = 
> *1827000* *uW / m^2*
>
>  
>
> Attached Radio Sound file :
>
> https://mega.nz/#!8thAzY5D!4ZfOmHLSttQKtYQQlz6BBVtV_vqjrVsxSRiJVzdnRqs
> 
>
>  
>
> Attached technical analysis in 84 pages ;
>
> https://mega.nz/#!YwplVCCT!Acbe00paHk3dLJuf04B5zSBifSw0-bHz5IciiNLgQwY
> 
>
>  
>
> I know that Radio Sound that can be analyst further.
>
> I am looking for external expert - urgently to help on this. Looking
> forward for your reply.
>
>  
>
> Regards
>
>  
>
>  
>
> Srinivasan T
>
> HP : 65 - 91236851
>
>  
>
> * *
>
> * *
>
> * *
>
>  
>
>  
>
>
>
> ___
> 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] comedi in grc

2016-02-10 Thread Yann Le Coq


Hello,

In the process of writing the xml files for gr-comedi in grc and testing 
the result, I believe I am getting in an gr-comedi issue.


The only comedi board I have access to is a USB-DUX Sigma, which outputs 
ADC data in the comedi type "lsampl_t" (32 bits per sample). The 
gr-comedi module, however, is hard coded for the comedi type "sampl_t" 
(16 bits per sample only).


The only way I see to make this work for the USB-DUX Sigma (or any other 
>16bits ADC equipped board) is to modify the gr-comedi module C source 
itself, so as to accomodate 32 bits ADC devices.


If I were to do this, I would, however, be tempted to change the output 
type entirely. The way it is done now, the comedi-device is expected to 
return "sampl_t" type raw data (unsigned 16 bits), which are then 
shifted down by -32767 and the resulting "signed and hopefully 
zero-centered" data is output as a short. There might be a good reason 
for that, but it seems more likely to be a quick hack, that has the 
drawback of making the whole module interface too device-dependant, IMHO.


The comedilib standard way would rather be to use the comedilib function 
"comedi_to_phys()", which takes raw data and makes it a float that 
actually represents a physical value (a voltage for example) based on 
the channel/board configuration (unipolar/bipolar, ADC range, etc.). 
This function helps a lot providing device-independence and I don't see 
good reason why gnu-radio shouldn't be using it. In fact, I don't see 
why one would want to have access to the raw data itself from gnuradio, 
especially if it means changing the output type depending on the device 
being used... Getting a physically meaningful float output seems to make 
ways more sense.


Doing this modification would, however, break backward compatibility 
with pre-existing gr-comedi-using top_blocks, so I am a bit hesitant and 
would like some feedback before investing the time that is necessary to 
make this change.


Best regards,

-Yann

Le 01/02/2016 18:19, Marcus Müller a écrit :

Hello Yann,

no, you're not missing something; I don't remember there ever being GRC
XML files for gr-comedi, but if there where pre-3.7, they might have
gone away during the restructuration for 3.7; and, as there seemed to be
very little interest in getting gr-comedi to work from within GRC

At any rate, since the sink and source have no own method and their
ctor/make functions only take sample rate and device address string as
arguments, copy&pasting together a valid XML file should be done very
quickly. However, I (used to think that I) don't know anyone who has
uses comed to talk to a data aquisition or signal generation device –
which would be useful for testing.

So, would you be willing to contribute such XML?

Best regards,
Marcus

On 01.02.2016 18:00, Yann Le Coq wrote:

Hello,

Unless I missed a point in compilation from source, there doesn't seem
to be a grc blocks for the comedi driver gnuradio interface in a
standard installation (origin/maint commit
11973c64437683cc99c48eae9eb4db8234f1ac42). Indeed, in the source code,
there is no /grc sub-folder in the gr-comedi folder to define the .xml
files.

Am I missing something, or is there a place somewhere where this can
be found ?

Thank you for your help.

-Yann



___
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] MME detection problem

2016-02-10 Thread Yan Huang

Hi all,

sorry I forgot to put my python script in last email.

I'm using python to build an OOT block to do Maximum-Minimum Eigenvalue 
detection, and I have followed the steps of the algorithm, but when I connect 
it to a signal source and number sink, it runs too slow and even no results, 
and the CPU occupation will come to near 100%.

I want to know the outcome of  signal source is a vector, but how many samples 
comes to next blocks every time? cos I want to reshape them as arrays to 
compute their covariance matrix. Are there any problems in my python script?

Thanks in advance

Yan




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# 
# Copyright 2016 <+YOU OR YOUR COMPANY+>.
# 
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
# 

import numpy
import scipy.linalg
import numpy.linalg
import math
from TracyWidom import * 
from gnuradio import gr


class MME(gr.sync_block):
"""
docstring for block MME
"""
def __init__(self,samples,slots,false,algo):
	self.samples = samples
	self.slots = slots
	self.false = false
	self.algo = algo
gr.sync_block.__init__(self,
name="MME",
in_sig=[numpy.float32],
out_sig=[numpy.float32])
'''
def R(self, x):
	x0 = x - numpy.mean(x)
	L = self.slots
	Ns = len(x0)
	lbd = numpy.empty(L)
	for l in xrange(L):
		if l > 0:
			xu = x0[:-l]
		else:
			xu = x0
			lbd[l] = numpy.dot(xu, x0[l:])/(Ns-l)

	return scipy.linalg.toeplitz(lbd)
'''
#compute the eigenvalues
def lbd(self, x):
	#R = self.R(x)
R = numpy.cov(x)  #compute the received sample covariance matrix
	lbd = numpy.linalg.eigvalsh(R)
	return numpy.abs(lbd)

#compute the threshold
def thr_MME(self,Ns,M,false):
	x = math.sqrt(Ns)+math.sqrt(M*Ns)
	y = math.sqrt(Ns)-math.sqrt(M*Ns)
	f = TracyWidom().cdfinv(1-false)
	thr1 = x*x/(y*y)*(1+x**(-2/3)/(M*Ns*Ns)**(1/6)*f)
return thr1

def work(self, input_items, output_items):
in0 = input_items[0]
out = output_items[0]
Ns = self.samples  #number of samples
M = self.slots #number of slots
	false = self.false #probability of false alarm
# <+signal processing here+>
n = len(in0)/Ns/M
in1 = numpy.array(in0)
in1 = in1[0:n*Ns*M:1]  #slice the array
in1 = numpy.reshape(in1,(n*M,Ns)) # >>> x = np.arange(16.0).reshape(4, 4)
in2 = numpy.split(in1,n)
if(self.algo == 0):#use MME detection
	for i in range(n):
	lbd = self.lbd(in2[i])
	lbd.sort()
	out[i] = lbd[-1]/lbd[0]
if (out[i] >= self.thr_MME(Ns,M,false)):
		out[i] = 1
else: 
		out[i] = 0
		
if(self.algo == 1):   #use EME detection
	for i in range(n):
	lbd = self.lbd(in2[i])
	lbd.sort()
	out[i] = numpy.sum(lbd**2)/lbd[0]
  
return len(output_items[0])

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

[Discuss-gnuradio] MME detection problem

2016-02-10 Thread Yan Huang

Hi all,

I'm using python to build an OOT block to do Maximum-Minimum Eigenvalue 
detection, and I have followed the steps of the algorithm, but when I connect 
it to a signal source and number sink, it runs too slow and even no results, 
and the CPU occupation will come to near 100%.

I want to know the outcome of  signal source is a vector, but how many samples 
comes to next blocks every time? cos I want to reshape them as arrays to 
compute their covariance matrix. Are there any problems in my python script?

Thanks in advance

Yan




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

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

Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

Re: [Discuss-gnuradio] GNU Radio Architecture and Implementation ?

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

Re: [Discuss-gnuradio] Tagged stream align duplicates tags

[Discuss-gnuradio] GNU Radio Architecture and Implementation ?

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

Re: [Discuss-gnuradio] Cant receive .wav file correctly

[Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue

[Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

Re: [Discuss-gnuradio] Pybombs Question

Re: [Discuss-gnuradio] Pybombs Question

[Discuss-gnuradio] Pybombs Question

Re: [Discuss-gnuradio] Building ControlPort support into OOT module

Re: [Discuss-gnuradio] Building ControlPort support into OOT module

[Discuss-gnuradio] Questions about transmit and receive with USRP N210 & GNU 3.6.5 use SBX dboard

[Discuss-gnuradio] Building ControlPort support into OOT module

Re: [Discuss-gnuradio] Using static variables in work function of an OOT module.

Re: [Discuss-gnuradio] Using static variables in work function of an OOT module.

Re: [Discuss-gnuradio] comedi in grc

Re: [Discuss-gnuradio] Re : Info on 2.4 GHz

Re: [Discuss-gnuradio] comedi in grc

[Discuss-gnuradio] MME detection problem

[Discuss-gnuradio] MME detection problem

31 matches

Site Navigation

Mail list logo

Footer information