Re: [Discuss-gnuradio] Phase change for Transmitted Signal Bursts - The relation to clock?

[Alex Zhang]

I just review this mail and want to ask when we try to send the burst data,
can we force the carrier phase to be a specified value at every beginning
of burst? If it can, does this procedure cost time or just take effect
within the sample time?

On Thu, Aug 8, 2013 at 4:53 PM, Marcus D. Leech  wrote:

> On 08/08/2013 05:25 PM, Alex Zhang wrote:
>
>> Hi,
>>
>> I am transmitting a series of BPSK burst signal and try to observe the
>> phase distortion for the BPSK signal on air. But it is found that the
>> Phases of different BPSK bursts are different.
>> I think this change is caused by the fact that the ADC clock phases are
>> different for the starts of every signal burst. But I don't know more
>> details on this mechanism.
>>
>> BR,
>>
>>  Indeed, the carrier phase for discontinous transmission will be at some
> random spot every time you start a burst.  The hardware doesn't have any
>   notion of "start the burst only when the clock phase is the same as it
> was last-time I sent a burst".  Unless you have utter blind luck, your
> burst timing
>   isn't ever going to be an exact multiple of the clock frequency, so
> there's no way the carrier phase will be in exactly the same place at the
> start of
>   every burst.
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 

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

[Discuss-gnuradio] iir_filter does not work with specified feedback taps?

[Alex Zhang]

Hi All,

Any guys who ever used IIR filters? I got problems as below:

I want the IIR filter works as:
y[n] = 1.8*x[n] + 0.8*y[n-1]
Then I set the feed forward taps as [1.8], feeback taps as [0.8], just like
self.iir_filter_xxx_0 = filter.iir_filter_ffd(([1.8]), ([0.8]), True)

But my testing result show that the feedback taps are not involved in
computing at all, thus my output turns to
y[n] = 1.8*x[n]

I don't know anything wrong happened to my usage...
Need help. Thanks

-- 

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

[Discuss-gnuradio] unexpected low frequency component in received USRP signal

[Alex Zhang]

Hello,

This is a radio problem I can not explain:

Transmitter: USRPN210, BPSK, linkrate = 100kbps, TX-gain=15
Receiver: USRPN210, Rx-gain=15
TX-RX: 1.5m.

Below is what the I/Q samples I get, after timing synchronization. There is
no center frequence offset as I share the same clk for tx and rx.

It looks like the if the I or Q amplitude is low, a frequency leakage is
displayed in this picture. I have used the tune_request for both the tx and
rx to the same offset of sample rate.

And I have monitored the radio spectrum by measuring the noise, no
interference is found.

Really confused for this observation.

-- 

Alex,
*Dreams can come true – just believe.*
<>___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio

[Alex Zhang]

Problem solved when ./build_gnuradio goes back to work.


On Fri, Sep 20, 2013 at 12:02 PM, Alex Zhang wrote:

> This is the error:
>
> > 1 import gnuradio.extras
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py in
> ()
>  21 import extras_pmt #act of importing performs injection
>  22 import block_gateway #act of importing performs injection
> ---> 23 import pmt_to_python #act of importing performs injection
>  24
>  25 try: #it may not exist based on prereqs
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/pmt_to_python.py in
> ()
>  76
>  77 THE_TABLE = ( #python type, check pmt type, to python, from python
> ---> 78 (None, pmt.pmt_is_null, lambda x: None, lambda x: pmt.PMT_NIL),
>  79 (bool, pmt.pmt_is_bool, pmt.pmt_to_bool, pmt.pmt_from_bool),
>  80 (str, pmt.pmt_is_symbol, pmt.pmt_symbol_to_string,
> pmt.pmt_string_to_symbol),
>
> AttributeError: 'module' object has no attribute 'pmt_is_null'
>
>
>
> On Fri, Sep 20, 2013 at 11:38 AM, Alex Zhang wrote:
>
>> Hello Josh,
>>
>> Today I met this problem again.
>> The gnuradio.extras can not be imported, with error of "pmt_is_null"
>> undefined in the extras.
>> even though the gnuraido version I am using is v3.6.5.1.
>> And the grextras can not be built at all due to some error.
>>
>>
>> On Tue, Aug 6, 2013 at 10:27 AM, Alex Zhang wrote:
>>
>>> Hi,
>>>
>>> I reinstalled the entire gnuradio using ./build-gnuradio -m. But when I
>>> try to import the gnuradio.extras, errors happened:
>>>
>>> In [1]: import gnuradio.extras
>>>
>>> ---
>>> ImportError   Traceback (most recent call
>>> last)
>>>  in ()
>>> > 1 import gnuradio.extras
>>>
>>> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py in
>>> ()
>>>  18 # Boston, MA 02110-1301, USA.
>>>  19
>>> ---> 20 from extras_swig import *
>>>  21 import extras_pmt #act of importing performs injection
>>>  22 import block_gateway #act of importing performs injection
>>>
>>> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
>>> ()
>>>  24 fp.close()
>>>  25 return _mod
>>> ---> 26 _extras_swig = swig_import_helper()
>>>  27 del swig_import_helper
>>>  28 else:
>>>
>>> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
>>> swig_import_helper()
>>>  20 if fp is not None:
>>>  21 try:
>>> ---> 22 _mod = imp.load_module('_extras_swig', fp,
>>> pathname, description)
>>>  23 finally:
>>>  24 fp.close()
>>>
>>> ImportError: libgnuradio-extras.so: cannot open shared object file: No
>>> such file or directory
>>>
>>> I run the sudo ldconfig after the whole installation, but the error
>>> still exists.
>>> Btw, do I need to install the GRAS manually?
>>>
>>>
>>> --
>>>
>>> Alex,
>>> *Dreams can come true – just believe.*
>>>
>>
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio

[Alex Zhang]

This is the error:

> 1 import gnuradio.extras

/usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py in
()
 21 import extras_pmt #act of importing performs injection
 22 import block_gateway #act of importing performs injection
---> 23 import pmt_to_python #act of importing performs injection
 24
 25 try: #it may not exist based on prereqs

/usr/local/lib/python2.7/dist-packages/gnuradio/extras/pmt_to_python.py in
()
 76
 77 THE_TABLE = ( #python type, check pmt type, to python, from python
---> 78 (None, pmt.pmt_is_null, lambda x: None, lambda x: pmt.PMT_NIL),
 79 (bool, pmt.pmt_is_bool, pmt.pmt_to_bool, pmt.pmt_from_bool),
 80 (str, pmt.pmt_is_symbol, pmt.pmt_symbol_to_string,
pmt.pmt_string_to_symbol),

AttributeError: 'module' object has no attribute 'pmt_is_null'



On Fri, Sep 20, 2013 at 11:38 AM, Alex Zhang wrote:

> Hello Josh,
>
> Today I met this problem again.
> The gnuradio.extras can not be imported, with error of "pmt_is_null"
> undefined in the extras.
> even though the gnuraido version I am using is v3.6.5.1.
> And the grextras can not be built at all due to some error.
>
>
> On Tue, Aug 6, 2013 at 10:27 AM, Alex Zhang wrote:
>
>> Hi,
>>
>> I reinstalled the entire gnuradio using ./build-gnuradio -m. But when I
>> try to import the gnuradio.extras, errors happened:
>>
>> In [1]: import gnuradio.extras
>>
>> ---
>> ImportError   Traceback (most recent call
>> last)
>>  in ()
>> > 1 import gnuradio.extras
>>
>> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py in
>> ()
>>  18 # Boston, MA 02110-1301, USA.
>>  19
>> ---> 20 from extras_swig import *
>>  21 import extras_pmt #act of importing performs injection
>>  22 import block_gateway #act of importing performs injection
>>
>> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
>> ()
>>  24 fp.close()
>>  25 return _mod
>> ---> 26 _extras_swig = swig_import_helper()
>>  27 del swig_import_helper
>>  28 else:
>>
>> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
>> swig_import_helper()
>>  20 if fp is not None:
>>  21 try:
>> ---> 22 _mod = imp.load_module('_extras_swig', fp,
>> pathname, description)
>>  23 finally:
>>  24 fp.close()
>>
>> ImportError: libgnuradio-extras.so: cannot open shared object file: No
>> such file or directory
>>
>> I run the sudo ldconfig after the whole installation, but the error still
>> exists.
>> Btw, do I need to install the GRAS manually?
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio

[Alex Zhang]

Hello Josh,

Today I met this problem again.
The gnuradio.extras can not be imported, with error of "pmt_is_null"
undefined in the extras.
even though the gnuraido version I am using is v3.6.5.1.
And the grextras can not be built at all due to some error.


On Tue, Aug 6, 2013 at 10:27 AM, Alex Zhang  wrote:

> Hi,
>
> I reinstalled the entire gnuradio using ./build-gnuradio -m. But when I
> try to import the gnuradio.extras, errors happened:
>
> In [1]: import gnuradio.extras
> ---
> ImportError   Traceback (most recent call last)
>  in ()
> > 1 import gnuradio.extras
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py in
> ()
>  18 # Boston, MA 02110-1301, USA.
>  19
> ---> 20 from extras_swig import *
>  21 import extras_pmt #act of importing performs injection
>  22 import block_gateway #act of importing performs injection
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
> ()
>  24 fp.close()
>  25 return _mod
> ---> 26 _extras_swig = swig_import_helper()
>  27 del swig_import_helper
>  28 else:
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
> swig_import_helper()
>  20 if fp is not None:
>  21 try:
> ---> 22 _mod = imp.load_module('_extras_swig', fp,
> pathname, description)
>  23 finally:
>  24 fp.close()
>
> ImportError: libgnuradio-extras.so: cannot open shared object file: No
> such file or directory
>
> I run the sudo ldconfig after the whole installation, but the error still
> exists.
> Btw, do I need to install the GRAS manually?
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [discuss-gnuradio] Git checkout error in build_gnuradio script

[Alex Zhang]

Hello,

I think the script build_gnuradio has an error when GNURadio 3.7 is in the
repository.
As the GNURadio 3.7 has no directory gnuradio-core. The below code will
always report error and exit the building.

git clone --progress http://gnuradio.org/git/gnuradio.git >>$LOGDEV 2>&1
if [ ! -d gnuradio/gnuradio-core -a ! -d 
gnuradio/gnuradio-runtime ]
then
my_echo "Could not find 
gnuradio/gnuradio-{core,runtime} after GIT checkout"
my_echo GIT checkout of Gnu Radio failed!
doexit FETCH-GR-FAIL
fi

It should be corrected, if I am not wrong.

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How can I measure the RSSI with SBX board

[Alex Zhang]

Hi all,

It is seen that the RSSI can be obtained by the read_aux_adc.
But I am not sure if SBX board supports it or not. And how to specify the
parameters:

int which_side, int which_adc

Any hints for this question?

Thanks!
-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to find 'pmt_swig_doc.i' when building v3.6.5.1

[Alex Zhang]

Oh, it's working with single-thread make...I did not expect this cause for
days.


On Tue, Sep 3, 2013 at 12:26 PM, Marcus D. Leech  wrote:

>  On 09/03/2013 01:20 PM, Alex Zhang wrote:
>
> Looks like nobody met this problem before?
>
>  What I did is:
> 1. git clone git://git.gnuradio.org/gnuradio
>  2. Enter the gnuradio and git checkout tags/v3.6.5.1
> 3. mkdir build and enter build do cmake ../
> 4. sudo make -j32
>
>  Then I got the error
>/home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i:39: Error:
> Unable to find 'pmt_swig_doc.i'
>
>  If I switch the source code to master branch and build the master
> (v3.7.2) firstly, and then switch back to v3.6.5.1. Without deleting the
> files in the build directory, just redo the cmake../ and sudo make, then
> this v3.6.5.1 can be built..
>  I can not understand what happened.
>
>  Try doing the make single-threaded.
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to find 'pmt_swig_doc.i' when building v3.6.5.1

[Alex Zhang]

yes, understand and thanks. :)

It could be good to add note for some specific version of gnuradio that
could fail in parallel make, in case other people don't realize it as I
did...


On Tue, Sep 3, 2013 at 3:53 PM, Marcus D. Leech  wrote:

> On 09/03/2013 04:44 PM, Alex Zhang wrote:
>
>> Oh, it's working with single-thread make...I did not expect this cause
>> for days.
>>
>>  Gnu Radio goes through phases of working with parallel-make, and not
> working with parallel make.  Paradoxically, it's much harder to make
>   large, complex projects work correctly with parallel make than smaller
> ones.  And, of course, it's the larger projects that benefit from
>   it the most, when it works.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to find 'pmt_swig_doc.i' when building v3.6.5.1

[Alex Zhang]

Looks like nobody met this problem before?

What I did is:
1. git clone git://git.gnuradio.org/gnuradio
2. Enter the gnuradio and git checkout tags/v3.6.5.1
3. mkdir build and enter build do cmake ../
4. sudo make -j32

Then I got the error
  /home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i:39: Error: Unable
to find 'pmt_swig_doc.i'

If I switch the source code to master branch and build the master (v3.7.2)
firstly, and then switch back to v3.6.5.1. Without deleting the files in
the build directory, just redo the cmake../ and sudo make, then this
v3.6.5.1 can be built..
I can not understand what happened.


On Tue, Sep 3, 2013 at 10:56 AM, Alex Zhang  wrote:

> hello,
>
> I git clone the gnuradio repositary and then checkout the tag v3.6.5.1 but
> when try to build gnuradio under v3.6.5.1, i got error like this:
>
> /home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i[ 31%] :39: Error:
> Unable to find 'pmt_swig_doc.i'
> make[2]: *** [gr-audio/swig/audio_swigPYTHON_wrap.cxx] Error 1
> make[1]: *** [gr-audio/swig/CMakeFiles/pygen_gr_audio_swig_ef4be.dir/all]
> Error 2
> Built target vocoder_swig_swig_doc
> /home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i:39: Error: Unable
> to find 'pmt_swig_doc.i'
> make[2]: *** [gr-wavelet/swig/wavelet_swigPYTHON_wrap.cxx] Error 1
> make[1]: ***
> [gr-wavelet/swig/CMakeFiles/pygen_gr_wavelet_swig_7d78f.dir/all] Error 2
> /home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i:39: Error: Unable
> to find 'pmt_swig_doc.i'
> make[2]: *** [gr-noaa/swig/noaa_swigPYTHON_wrap.cxx] Error 1
> make[1]: *** [gr-noaa/swig/CMakeFiles/pygen_gr_noaa_swig_78db7.dir/all]
> Error 2
> /home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i:39: Error: Unable
> to find 'pmt_swig_doc.i'
> make[2]: *** [gr-video-sdl/src/video_sdlPYTHON_wrap.cxx] Error 1
> make[1]: ***
> [gr-video-sdl/src/CMakeFiles/pygen_gr_video_sdl_src_43074.dir/all] Error 2
>
> what is the possible cause? Anything wrong i did?
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Unable to find 'pmt_swig_doc.i' when building v3.6.5.1

[Alex Zhang]

hello,

I git clone the gnuradio repositary and then checkout the tag v3.6.5.1 but
when try to build gnuradio under v3.6.5.1, i got error like this:

/home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i[ 31%] :39: Error:
Unable to find 'pmt_swig_doc.i'
make[2]: *** [gr-audio/swig/audio_swigPYTHON_wrap.cxx] Error 1
make[1]: *** [gr-audio/swig/CMakeFiles/pygen_gr_audio_swig_ef4be.dir/all]
Error 2
Built target vocoder_swig_swig_doc
/home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i:39: Error: Unable
to find 'pmt_swig_doc.i'
make[2]: *** [gr-wavelet/swig/wavelet_swigPYTHON_wrap.cxx] Error 1
make[1]: ***
[gr-wavelet/swig/CMakeFiles/pygen_gr_wavelet_swig_7d78f.dir/all] Error 2
/home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i:39: Error: Unable
to find 'pmt_swig_doc.i'
make[2]: *** [gr-noaa/swig/noaa_swigPYTHON_wrap.cxx] Error 1
make[1]: *** [gr-noaa/swig/CMakeFiles/pygen_gr_noaa_swig_78db7.dir/all]
Error 2
/home/alexzh/gr_alex/gnuradio/gruel/src/swig/pmt_swig.i:39: Error: Unable
to find 'pmt_swig_doc.i'
make[2]: *** [gr-video-sdl/src/video_sdlPYTHON_wrap.cxx] Error 1
make[1]: ***
[gr-video-sdl/src/CMakeFiles/pygen_gr_video_sdl_src_43074.dir/all] Error 2

what is the possible cause? Anything wrong i did?

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Phase change for Transmitted Signal Bursts - The relation to clock?

[Alex Zhang]

Hi,

I am transmitting a series of BPSK burst signal and try to observe the
phase distortion for the BPSK signal on air. But it is found that the
Phases of different BPSK bursts are different.
I think this change is caused by the fact that the ADC clock phases are
different for the starts of every signal burst. But I don't know more
details on this mechanism.

BR,

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio

[Alex Zhang]

Thanks, I have rolled back my gnuradio to v3.6 to support the pre-cog now.


On Tue, Aug 6, 2013 at 7:55 PM, Josh Blum  wrote:

>
> >
> > ImportError: libgnuradio-extras.so: cannot open shared object file: No
> such
> > file or directory
> >
> > I run the sudo ldconfig after the whole installation, but the error still
> > exists.
> > Btw, do I need to install the GRAS manually?
> >
> >
>
> If you want grextras installed to support precog or perhaps an older
> existing design. You need to first install gnuradio 3.6, then install
> grextras from the grextras_v3.6 branch. Due to the reorg in gr 3.7, this
> grextras is no longer build-able with recent gnuradio:
> https://github.com/guruofquality/grextras/wiki/Old
>
> If you are looking to install the recent GrExtras for the cool blocks,
> its automatically built and installed with GRAS, so just follow:
> https://github.com/guruofquality/gras/wiki/Build
>
> -josh
>
> >
> >
> > ___
> > 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
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Error in building GRAS

[Alex Zhang]

Hello,

When run the make, i got error today:

/home/alexzh/gras/lib/jit_factory.cpp:88:8: error: ‘llvm’ does not name a
type
/home/alexzh/gras/lib/jit_factory.cpp:238:6: error: ‘Factory’ has not been
declared
make[2]: *** [lib/CMakeFiles/gras.dir/jit_factory.cpp.o] Error 1
make[1]: *** [lib/CMakeFiles/gras.dir/all] Error 2
make: *** [all] Error 2


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio

[Alex Zhang]

I tried to reinstall the grextras, but:

~/grextras/build$ cmake ../
CMake Error at CMakeLists.txt:34 (include):
  include could not find load file:

GRASTool


CMake Error at math/CMakeLists.txt:20 (GRAS_TOOL):
  Unknown CMake command "GRAS_TOOL".


-- Configuring incomplete, errors occurred!


Who can tell me how to fix this error?


On Tue, Aug 6, 2013 at 10:27 AM, Alex Zhang  wrote:

> Hi,
>
> I reinstalled the entire gnuradio using ./build-gnuradio -m. But when I
> try to import the gnuradio.extras, errors happened:
>
> In [1]: import gnuradio.extras
> ---
> ImportError   Traceback (most recent call last)
>  in ()
> > 1 import gnuradio.extras
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py in
> ()
>  18 # Boston, MA 02110-1301, USA.
>  19
> ---> 20 from extras_swig import *
>  21 import extras_pmt #act of importing performs injection
>  22 import block_gateway #act of importing performs injection
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
> ()
>  24 fp.close()
>  25 return _mod
> ---> 26 _extras_swig = swig_import_helper()
>  27 del swig_import_helper
>  28 else:
>
> /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
> swig_import_helper()
>  20 if fp is not None:
>  21 try:
> ---> 22 _mod = imp.load_module('_extras_swig', fp,
> pathname, description)
>  23 finally:
>  24 fp.close()
>
> ImportError: libgnuradio-extras.so: cannot open shared object file: No
> such file or directory
>
> I run the sudo ldconfig after the whole installation, but the error still
> exists.
> Btw, do I need to install the GRAS manually?
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio

[Alex Zhang]

Hi,

I reinstalled the entire gnuradio using ./build-gnuradio -m. But when I try
to import the gnuradio.extras, errors happened:

In [1]: import gnuradio.extras
---
ImportError   Traceback (most recent call last)
 in ()
> 1 import gnuradio.extras

/usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py in
()
 18 # Boston, MA 02110-1301, USA.
 19
---> 20 from extras_swig import *
 21 import extras_pmt #act of importing performs injection
 22 import block_gateway #act of importing performs injection

/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
()
 24 fp.close()
 25 return _mod
---> 26 _extras_swig = swig_import_helper()
 27 del swig_import_helper
 28 else:

/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py in
swig_import_helper()
 20 if fp is not None:
 21 try:
---> 22 _mod = imp.load_module('_extras_swig', fp,
pathname, description)
 23 finally:
 24 fp.close()

ImportError: libgnuradio-extras.so: cannot open shared object file: No such
file or directory

I run the sudo ldconfig after the whole installation, but the error still
exists.
Btw, do I need to install the GRAS manually?


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] maybe the build-gnuradio needs to update the git clone address?

[Alex Zhang]

That's great. Thanks!


On Fri, Aug 2, 2013 at 12:21 PM, Johnathan Corgan
wrote:

> On 08/02/2013 09:38 AM, Alex Zhang wrote:
>
> > Is there any problem with the current git clone address
> >
> > http://gnuradio.org/git/gnuradio.git
>
> This should be fixed now; there was some subtle corruption of the git
> database that affected checkouts over HTTP.
>
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
> Visit us at GRCON13 Oct. 1-4 http://ow.ly/ntmpL
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] maybe the build-gnuradio needs to update the git clone address?

[Alex Zhang]

Hi Marcus,

I always met the git checkout error
" Could not find gnuradio/gnuradio-{core,runtime} after GIT checkout"

Thus everytime i have to change the git clone address to

git://git.gnuradio.org/gnuradio


Is there any problem with the current git clone address

http://gnuradio.org/git/gnuradio.git


Best regards,

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] channel estimation in gnuradio narrowband

[Alex Zhang]

Hi yeran,

I am wondering if you have solved this problem?

Best Regards,


On Wed, May 29, 2013 at 9:43 PM, yeran  wrote:

> Hi everyone,
>
>
> I’m doing channel estimation in gnu radio narrowband. But the result is
> different than I expect.
>
>
> I’m using the example in grc, uhd_tx_dpsk.grc and uhd_rx_dpsk.grc. Send
> vector (255,255,255) repeatedly using BPSK.  At the receiver, I add a file
> sink after the time_recov block and store the data.
>
>
> Y=X*H +N,  the data after time_recov is Y, and in BPSK, when sending 1 is
> mapped to 1+0j, so X=1+0j. Thus, Y/X is the estimate channel frequency I
> get. I plot the absolute value of the channel frequency and get a figure as
> in the attachment. But it seems that it has the carrier frequency with it.
> It is so well organized and changes regularly. But I’m pretty sure that
> before the file sink, in the time_recov block, the rrc filter already take
> off the carrier frequency.
>
>
> Has anyone come across the same problem before? Or find any mistakes or
> suggestions on my method? Please let me know!
>
>
> Thank you very much!
>
> Ada
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [USRP-users] driver mode for the external ref clock port of N210

[Alex Zhang]

hello,

I am going to connect the N210 external ref port to a clock distribution
board. But I dont know what the driver mode is. Such like it is LVDS or
else, and what the current is, like 3.5mA or 8mA.

Can some one give help?
Thanks

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how to get started with python in gnuradio

[Alex Zhang]

suppose your python file is run.py.
In terminal, just use  ./run.py in the directory where the file is placed.


On Sun, Jun 9, 2013 at 8:48 PM, vamshi krishna dodla <
vamshikrishna.do...@gmail.com> wrote:

> Hi all
> It would be very helpful to me if some one tells me how to get started
> with python in gnu radio.I see an entire page dedicated to python
> programming but it does not say anything about getting started.Please don't
> say to use #!/usr/bin/env /python part in that page.Any link to how to
> get started with an example would be helpful.
>
>
>
> --
> Thanks & Regards
> Vamshi Krishna Dodla
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] channel estimation in gnuradio narrowband

[Alex Zhang]

So, actually, your code already has the freq recov block? If so, I really
have no idea on how to solve your problem.


On Wed, May 29, 2013 at 11:34 PM, yeran  wrote:

> Hi Alex,
>
> I have read the  generic_mod_demod.py and find the fll block you
> mentioned is in freq_recov block, which is before the time_recov block.
> However, the file sink I use to collect data is after time_recov block. So
> I think in this case, it's already been through carrier frequency
> correction. But as shown in the picture I attached with the original email,
> the channel I get still seems to be with carrier frequency.
>
> Please correct me if there is a misunderstanding in my thought!
>
> Thanks! Look forward to your reply!!
>
> Best,
> Ada
>
> --
> Date: Wed, 29 May 2013 22:27:14 -0500
>
> Subject: Re: [Discuss-gnuradio] channel estimation in gnuradio narrowband
> From: cingular.a...@gmail.com
> To: yeran0...@hotmail.com; discuss-gnuradio@gnu.org
>
>
> FLL = Frequency lock looping.
> The corresponding C++ block is digital_fll_band_edge_cc.
> and you can find the usage example in generic_mod_demod.py in
> /gnuradio/gr-digtial/python.
> There are some discussions within this community before, just search it
> for how to use it properly.
>
>
> On Wed, May 29, 2013 at 10:07 PM, yeran  wrote:
>
> Hi Alex,
>
> Thank you for your prompt reply!
>
> But I don't quite understand what you said about FLL filter for CFO
> correction. What is the full name of the FLL filter? In which block?
>
> Thanks! Look forward to your reply!
>
> Ada
>
> --
> Date: Wed, 29 May 2013 21:55:29 -0500
> Subject: Re: [Discuss-gnuradio] channel estimation in gnuradio narrowband
> From: cingular.a...@gmail.com
> To: yeran0...@hotmail.com
> CC: discuss-gnuradio@gnu.org
>
>
> I don't think the RRC filter is used for carrier frequency correction. In
> gnuradio, the FLL filter can be used for CFO correction.
> Please correct me if I am wrong.
>
>
> On Wed, May 29, 2013 at 9:43 PM, yeran  wrote:
>
> Hi everyone,
>
>
> I’m doing channel estimation in gnu radio narrowband. But the result is
> different than I expect.
>
>
> I’m using the example in grc, uhd_tx_dpsk.grc and uhd_rx_dpsk.grc. Send
> vector (255,255,255) repeatedly using BPSK.  At the receiver, I add a file
> sink after the time_recov block and store the data.
>
>
> Y=X*H +N,  the data after time_recov is Y, and in BPSK, when sending 1 is
> mapped to 1+0j, so X=1+0j. Thus, Y/X is the estimate channel frequency I
> get. I plot the absolute value of the channel frequency and get a figure as
> in the attachment. But it seems that it has the carrier frequency with it.
> It is so well organized and changes regularly. But I’m pretty sure that
> before the file sink, in the time_recov block, the rrc filter already take
> off the carrier frequency.
>
>
> Has anyone come across the same problem before? Or find any mistakes or
> suggestions on my method? Please let me know!
>
>
> Thank you very much!
>
> Ada
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] channel estimation in gnuradio narrowband

[Alex Zhang]

FLL = Frequency lock looping.
The corresponding C++ block is digital_fll_band_edge_cc.
and you can find the usage example in generic_mod_demod.py in
/gnuradio/gr-digtial/python.
There are some discussions within this community before, just search it for
how to use it properly.


On Wed, May 29, 2013 at 10:07 PM, yeran  wrote:

> Hi Alex,
>
> Thank you for your prompt reply!
>
> But I don't quite understand what you said about FLL filter for CFO
> correction. What is the full name of the FLL filter? In which block?
>
> Thanks! Look forward to your reply!
>
> Ada
>
> --
> Date: Wed, 29 May 2013 21:55:29 -0500
> Subject: Re: [Discuss-gnuradio] channel estimation in gnuradio narrowband
> From: cingular.a...@gmail.com
> To: yeran0...@hotmail.com
> CC: discuss-gnuradio@gnu.org
>
>
> I don't think the RRC filter is used for carrier frequency correction. In
> gnuradio, the FLL filter can be used for CFO correction.
> Please correct me if I am wrong.
>
>
> On Wed, May 29, 2013 at 9:43 PM, yeran  wrote:
>
> Hi everyone,
>
>
> I’m doing channel estimation in gnu radio narrowband. But the result is
> different than I expect.
>
>
> I’m using the example in grc, uhd_tx_dpsk.grc and uhd_rx_dpsk.grc. Send
> vector (255,255,255) repeatedly using BPSK.  At the receiver, I add a file
> sink after the time_recov block and store the data.
>
>
> Y=X*H +N,  the data after time_recov is Y, and in BPSK, when sending 1 is
> mapped to 1+0j, so X=1+0j. Thus, Y/X is the estimate channel frequency I
> get. I plot the absolute value of the channel frequency and get a figure as
> in the attachment. But it seems that it has the carrier frequency with it.
> It is so well organized and changes regularly. But I’m pretty sure that
> before the file sink, in the time_recov block, the rrc filter already take
> off the carrier frequency.
>
>
> Has anyone come across the same problem before? Or find any mistakes or
> suggestions on my method? Please let me know!
>
>
> Thank you very much!
>
> Ada
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] channel estimation in gnuradio narrowband

[Alex Zhang]

I don't think the RRC filter is used for carrier frequency correction. In
gnuradio, the FLL filter can be used for CFO correction.
Please correct me if I am wrong.


On Wed, May 29, 2013 at 9:43 PM, yeran  wrote:

> Hi everyone,
>
>
> I’m doing channel estimation in gnu radio narrowband. But the result is
> different than I expect.
>
>
> I’m using the example in grc, uhd_tx_dpsk.grc and uhd_rx_dpsk.grc. Send
> vector (255,255,255) repeatedly using BPSK.  At the receiver, I add a file
> sink after the time_recov block and store the data.
>
>
> Y=X*H +N,  the data after time_recov is Y, and in BPSK, when sending 1 is
> mapped to 1+0j, so X=1+0j. Thus, Y/X is the estimate channel frequency I
> get. I plot the absolute value of the channel frequency and get a figure as
> in the attachment. But it seems that it has the carrier frequency with it.
> It is so well organized and changes regularly. But I’m pretty sure that
> before the file sink, in the time_recov block, the rrc filter already take
> off the carrier frequency.
>
>
> Has anyone come across the same problem before? Or find any mistakes or
> suggestions on my method? Please let me know!
>
>
> Thank you very much!
>
> Ada
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Import error of grextras, undefined symbol

[Alex Zhang]

try to remove all the existing gnuradio and then reinstall bu
./build_gnuradio.


On Mon, May 27, 2013 at 4:36 PM, Guy Holtzman  wrote:

> I am already working with the latest version of GNU Radio.
> in which dir the libgnuradio-extras.so should appear and, which package
> bulids it? is this file bring renamed during the build?
>
>
> On Mon, May 27, 2013 at 9:02 PM, Alex Zhang wrote:
>
>> I remember that I reinstall  to the latest gnuradio  entirely and then
>> the error disappeared.
>>
>>
>> On Mon, May 27, 2013 at 12:36 PM, Guy Holtzman  wrote:
>>
>>> I am having the same issue, I tried Josh suggestion without success.
>>> I have installed Extras and pre-cog using:
>>> https://github.com/jmalsbury/pre-cog/wiki/Installation
>>>
>>> what should I do to make it work?
>>>
>>>
>>>
>>>
>>> here is a error log containing the versions I am using:
>>>
>>> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
>>>
>>> <<< Welcome to GNU Radio Companion 3.6.4.1 >>>
>>>
>>> Loading: "/home/guy/Documents/tdma_hier.grc"
>>> >>> Done
>>>
>>> Showing: "/home/guy/Documents/tdma_hier.grc"
>>>
>>> Loading: "/home/guy/Documents/tdma_radio.grc"
>>> >>> Done
>>>
>>> Showing: "/home/guy/Documents/tdma_radio.grc"
>>>
>>> Generating: "/home/guy/Documents/tdma_radio.py"
>>> >>> Warning: This flow graph may not have flow control: no audio or usrp
>>> blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU
>>> congestion.
>>>
>>> Executing: "/home/guy/Documents/tdma_radio.py"
>>>
>>> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
>>>
>>> Traceback (most recent call last):
>>>   File "/home/guy/Documents/tdma_radio.py", line 8, in 
>>> execfile("/home/guy/.grc_gnuradio/tdma_hier.py")
>>>   File "/home/guy/.grc_gnuradio/tdma_hier.py", line 14, in 
>>>
>>> import gnuradio.extras as gr_extras
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py", line
>>> 20, in 
>>> from extras_swig import *
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
>>> line 26, in 
>>> _extras_swig = swig_import_helper()
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
>>> line 22, in swig_import_helper
>>> _mod = imp.load_module('_extras_swig', fp, pathname, description)
>>> ImportError: libgnuradio-extras.so: cannot open shared object file: No
>>> such file or directory
>>>
>>>
>>>
>>>  Thanks, Guy
>>>
>>>
>>>
>>> On Wed, Feb 20, 2013 at 8:22 PM, Alex Zhang wrote:
>>>
>>>> Maybe it is due to my own building which is very obsolete. I will try
>>>> to reinstall the latest version of gnuradio and grextras.
>>>>
>>>>
>>>> On Tue, Feb 19, 2013 at 5:35 PM, Alex Zhang wrote:
>>>>
>>>>> It does not work after the modification and rebuilding of the grextras.
>>>>>
>>>>> My modification:
>>>>>
>>>>> diff --git a/swig/CMakeLists.txt b/swig/CMakeLists.txt
>>>>> index 129d789..42732a3 100644
>>>>> --- a/swig/CMakeLists.txt
>>>>> +++ b/swig/CMakeLists.txt
>>>>> @@ -58,7 +58,7 @@ foreach(incdir ${GRUEL_INCLUDE_DIRS})
>>>>>  list(APPEND GR_SWIG_INCLUDE_DIRS ${incdir}/gruel/swig)
>>>>>  endforeach(incdir)
>>>>>
>>>>> -set(GR_SWIG_LIBRARIES gnuradio-extras)
>>>>> +list(APPEND GR_SWIG_LIBRARIES gnuradio-extras
>>>>> ${GNURADIO_CORE_LIBRARIES} ${G
>>>>>  set(GR_SWIG_DOC_FILE ${CMAKE_CURRENT_BINARY_DIR}/extras_swig_doc.i)
>>>>>  set(GR_SWIG_DOC_DIRS
>>>>> ${CMAKE_CURRENT_SOURCE_DIR}/../include/gnuradio/extras)
>>>>>
>>>>>
>>>>> On Tue, Feb 19, 2013 at 5:06 PM, Josh Blum  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 02/19/2013 04:59 PM, Alex Zhang wrote:
>>>>>> > Hi,
>>>>>> &g

Re: [Discuss-gnuradio] Import error of grextras, undefined symbol

[Alex Zhang]

I remember that I reinstall  to the latest gnuradio  entirely and then the
error disappeared.


On Mon, May 27, 2013 at 12:36 PM, Guy Holtzman  wrote:

> I am having the same issue, I tried Josh suggestion without success.
> I have installed Extras and pre-cog using:
> https://github.com/jmalsbury/pre-cog/wiki/Installation
>
> what should I do to make it work?
>
>
>
>
> here is a error log containing the versions I am using:
>
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
>
> <<< Welcome to GNU Radio Companion 3.6.4.1 >>>
>
> Loading: "/home/guy/Documents/tdma_hier.grc"
> >>> Done
>
> Showing: "/home/guy/Documents/tdma_hier.grc"
>
> Loading: "/home/guy/Documents/tdma_radio.grc"
> >>> Done
>
> Showing: "/home/guy/Documents/tdma_radio.grc"
>
> Generating: "/home/guy/Documents/tdma_radio.py"
> >>> Warning: This flow graph may not have flow control: no audio or usrp
> blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU
> congestion.
>
> Executing: "/home/guy/Documents/tdma_radio.py"
>
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
>
> Traceback (most recent call last):
>   File "/home/guy/Documents/tdma_radio.py", line 8, in 
> execfile("/home/guy/.grc_gnuradio/tdma_hier.py")
>   File "/home/guy/.grc_gnuradio/tdma_hier.py", line 14, in 
>
> import gnuradio.extras as gr_extras
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py", line
> 20, in 
> from extras_swig import *
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
> line 26, in 
> _extras_swig = swig_import_helper()
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
> line 22, in swig_import_helper
> _mod = imp.load_module('_extras_swig', fp, pathname, description)
> ImportError: libgnuradio-extras.so: cannot open shared object file: No
> such file or directory
>
>
>
> Thanks, Guy
>
>
>
> On Wed, Feb 20, 2013 at 8:22 PM, Alex Zhang wrote:
>
>> Maybe it is due to my own building which is very obsolete. I will try to
>> reinstall the latest version of gnuradio and grextras.
>>
>>
>> On Tue, Feb 19, 2013 at 5:35 PM, Alex Zhang wrote:
>>
>>> It does not work after the modification and rebuilding of the grextras.
>>>
>>> My modification:
>>>
>>> diff --git a/swig/CMakeLists.txt b/swig/CMakeLists.txt
>>> index 129d789..42732a3 100644
>>> --- a/swig/CMakeLists.txt
>>> +++ b/swig/CMakeLists.txt
>>> @@ -58,7 +58,7 @@ foreach(incdir ${GRUEL_INCLUDE_DIRS})
>>>  list(APPEND GR_SWIG_INCLUDE_DIRS ${incdir}/gruel/swig)
>>>  endforeach(incdir)
>>>
>>> -set(GR_SWIG_LIBRARIES gnuradio-extras)
>>> +list(APPEND GR_SWIG_LIBRARIES gnuradio-extras
>>> ${GNURADIO_CORE_LIBRARIES} ${G
>>>  set(GR_SWIG_DOC_FILE ${CMAKE_CURRENT_BINARY_DIR}/extras_swig_doc.i)
>>>  set(GR_SWIG_DOC_DIRS
>>> ${CMAKE_CURRENT_SOURCE_DIR}/../include/gnuradio/extras)
>>>
>>>
>>> On Tue, Feb 19, 2013 at 5:06 PM, Josh Blum  wrote:
>>>
>>>>
>>>>
>>>> On 02/19/2013 04:59 PM, Alex Zhang wrote:
>>>> > Hi,
>>>> >
>>>> > I believe some other guys met this problem before, but I did not find
>>>> the
>>>> > final solution expressed clearly.
>>>> >
>>>> > After I installed the gnuradio, grextras, then in my python code
>>>> which trys
>>>> > to import the extras_swig  like
>>>> >
>>>> > import gnuradio.extras as gr_extras
>>>> >   File
>>>> > "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py",
>>>> line
>>>> > 20, in 
>>>> > from extras_swig import *
>>>> >   File
>>>> >
>>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
>>>> > line 26, in 
>>>> > _extras_swig = swig_import_helper()
>>>> >   File
>>>> >
>>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
>>>> > line 22, in swig_import_helper
>>>> > _mod = imp.load_module('_extras_swig', fp, pathname, description)
>>>> > Import

[Discuss-gnuradio] Regarding on the new OFDM implementation.

[Alex Zhang]

Hi,

It is excited to see the new OFDM implementation has been merged and test
in the GNURadio master branch. Several Questions:
1. What are the main changes from the old design?
2. Seems it support NC-OFDM as the user can arrange the carriers? And how
is the gain of dB between the occupied carriers and vacant carriers?
3. How about the data rate which is the supported by the new design?

Will find a time to evaluate the tx_ofdm.grc and rx_ofdm.grc, but still
looking forward to the answers of the above questions.

Best Regards,

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] peak near center freq for noise signal, how to fix it

[Alex Zhang]

Veghihat, Hope this can help you
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-October/005376.html


On Mon, Apr 29, 2013 at 8:24 AM, vegihat vegihat wrote:

> Well as you advice me, i set the --lo-offset=1M , for the following
> command
>
> uhd_rx_cfile -a serial=4759a751 -N 10 -f 2.53G --samp-rate=2M
> --lo-offset=1M noise.dat -v
>
> However the peak is still there. I give below the output of
> uhd_rx_cfile.py.
> As you can see the Rx DDC frequency is -2M (if I have understood
> correctly, it should be 1M,right?  )
>
> Any idea what is the wrong..
>
>
> linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.005.002-47-g4a860d74
>
> -- Opening a USRP1 device...
> -- Using FPGA clock rate of 64.00MHz...
> Using mid-point gain of 45.0 ( 0.0 - 90.0 )
> Motherboard: USRP1 (4759a751)
> Daughterboard: RFX2400 (no serial, RX2, A:0)
> Rx gain: 45.0
> Rx baseband frequency: 2.528G
> Rx DDC frequency: -2M
> Rx Sample Rate: 2M
> Receving 100k samples
> Writing 32-bit complex floats
> Output filename: noise.dat
>
>
>
> 2013/4/28 Alex Zhang 
>
>> I remember that some DC is manually added into the frequency point which
>> can be divided by 5Mhz or 10Mhz? Besides the DC at the your central freq,
>> be aware of that if the lo offset setting makes your bandwidth cover these
>> frequency point, you still can see the peaks.
>> Hope I am not wrong, at least It seems that I observed that thing before.
>>
>>
>> On Fri, Apr 26, 2013 at 1:44 PM, Marcus D. Leech wrote:
>>
>>> On 04/26/2013 02:27 PM, vegihat vegihat wrote:
>>>
>>>> if i have understand i need to use the --lo-offset of uhd_rx_cfile
>>>>
>>>> i have gave various values to  --lo-offset and only one value has moved
>>>> the DC offset (--lo-offset=1G) and the plotfft gives many small spikes
>>>> (maybe this is caused to aliasing, but i am not sure)
>>>>
>>>> which is the rule (value of --lo-offset) to set the DC offset out of my
>>>> band?
>>>>
>>> What I do is set my LO offset to about half my bandwidth, so in your
>>> case:
>>>
>>> --lo-offset 1.0e6
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium
>>> http://www.sbrac.org
>>>
>>>
>>>
>>> __**_
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>
>>
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] peak near center freq for noise signal, how to fix it

[Alex Zhang]

I remember that some DC is manually added into the frequency point which
can be divided by 5Mhz or 10Mhz? Besides the DC at the your central freq,
be aware of that if the lo offset setting makes your bandwidth cover these
frequency point, you still can see the peaks.
Hope I am not wrong, at least It seems that I observed that thing before.


On Fri, Apr 26, 2013 at 1:44 PM, Marcus D. Leech  wrote:

> On 04/26/2013 02:27 PM, vegihat vegihat wrote:
>
>> if i have understand i need to use the --lo-offset of uhd_rx_cfile
>>
>> i have gave various values to  --lo-offset and only one value has moved
>> the DC offset (--lo-offset=1G) and the plotfft gives many small spikes
>> (maybe this is caused to aliasing, but i am not sure)
>>
>> which is the rule (value of --lo-offset) to set the DC offset out of my
>> band?
>>
> What I do is set my LO offset to about half my bandwidth, so in your case:
>
> --lo-offset 1.0e6
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] On tunnel.py

[Alex Zhang]

Totally agree to stop using the tunnel.py!

Just want to add some my thoughts.

There is a fact that the main users of USRP/GNURadio are the students from
universities.
Firstly, these people lack the experience on the
communications development, either in software designing or in wireless
communications theory.
Secondly, the reasons why they select the USRP/GNURadio as the development
platform for their research, as my understanding is that they (including I)
expect the USRP/GNURadio can provide a very quick solution to build a
experimental physical layer for the research over this platform. Actually,
most of the time, this pressure comes from their professors who are only
focused on advanced research of a narrow area, but don't tolerate too much
time of a student on the whole system development. This is the background
in which why so many people always try to find the out-of-the-box solution
in GNURadio/USRP.

I don't want to put negative points to this kind of expectation, but it
seems to be just reality. It may give us a hint how the GNURadio/USRP is
evolving from the customers' expect.
USRP/GNURadio are great work in establishing a flexible framework of
software defined radio. But as Tom said, the communications itself is very
very hard. How to help the customer to build a robust and strong radio
communication system in their specific research needs is really a big
challenge. I think the community needs more technical discussion
the communications and signal processing theory in practical ways, besides
the software development only.
Also, the  GNURadio itself need more evolution on the demonstrative
solutions of the communications, like the OFDM in improving.

And of course, this is a open source community. The GNURadio needs
everyone's contribution, including both issues reports and new
developments, new applications.


On Fri, Mar 29, 2013 at 11:39 AM, Tom Rondeau  wrote:

> Please, everyone, listen up.
>
> There's been a ton of traffic on the mailing list regarding tunnel.py
> (and I bet I know why). I want you all to pay close attention to what
> I'm going to say regarding how to get tunnel.py to work for you:
>
> Stop using tunnel.py.
>
> It's old. It hasn't had any significant work or updates in years.
> Meanwhile, we've made huge leaps in capabilities and features in GNU
> Radio. A lot has changed, including the switch to the UHD drivers,
> which also impacts how things work.
>
> You can do better. The stream tags and message passing system provide
> a significant amount of new capabilities that can help us make much
> better digital transceivers. Johnathan Corgan recently wrote to the
> mailing list discussing other projects working on improving these
> examples:
> https://lists.gnu.org/archive/html/discuss-gnuradio/2013-03/msg00014.html
>
> Take a look at the work that's been going into the OFDM examples
> lately. Martin Braun and Ben Reynwar have used stream tags effectively
> to provide information on packet boundaries and trigger conditions for
> receiver synchronization. And they've done it all in GRC so it's
> easier to understand the flowgraph, modify it, and hopefully even
> replace blocks. [1]
>
> Also, recognize that tunnel.py and the benchmark scripts are provided
> as /examples/. They were never meant nor installed as applications.
> They are there to help you understand how to put blocks together and
> interact with Python, C++, callback functions, OS tools, etc. etc. But
> they are not going to solve you digital transmission problems.
>
> GNU Radio is a platform to develop radio applications. You have to use
> it as a development tool, not an out-of-the-box solution.
>
> I say this because I want us to do better as a community. We've been
> held back for too long because people think that the benchmark and
> tunnel.py scripts are the final word in GNU Radio's digital
> communications capabilities. But that's what you are for! You can help
> us improve it, like Ben and Martin did with the OFDM work. It's not
> easy, but communications is not easy. In fact, it's very, very hard.
>
> Tom
>
> [1] There's still a bug in the new OFDM work. Marin, Johnathan C. and
> myself figured it out yesterday, but I'm still formatting the right
> way to patch it.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Alex Zhang]

Yes, that is what I am thinking. And try to solve this problem for the
non-differential bpsk.
Can the known preamble can solve this problem? I am investigate this way.


On Sat, Mar 16, 2013 at 9:18 AM, Tom Rondeau  wrote:

> On Fri, Mar 15, 2013 at 11:33 PM, Alex Zhang 
> wrote:
> > Hi Sreeraj and Tom,
> >
> > For the discontinuous mode, by cutting the freq_bw to below half of the
> > default value, I found that for differential_bpsk, the packet loss rate
> can
> > be improved(from 30% to 70%), but for non-differential bpsk, the
> improvement
> > is hard to see. Especially, for non-differential bpsk, I found that often
> > the whole burst (5 packets) could lost. Maybe, it is due to the Phase
> > rotation. I am still trying to investigate.
>
> Are you handling the phase ambiguity in the receiver somehow? The way
> things lock, the phases for BPSK could off by 180 degrees, so all 1's
> are 0's and all 0's are 1's. So when you lock with a burst, you have a
> 50/50 chance of locking on the wrong phase and so all of your bits are
> going to be wrong. You'd have to detect this and flip everything.
>
> Tom
>
>
> > On Thu, Mar 7, 2013 at 11:08 AM, Sreeraj Rajendran <
> srees4sr...@yahoo.co.in>
> > wrote:
> >>
> >> Alex,
> >>
> >> That one is non data aided(no preamble) frequency syncronization. As Tom
> >> mentioned FLL must be the slowest one in the three.
> >>
> >> Did you try adjusting loop bandwidth?. There is an example_fll example
> in
> >> gr-digial. Just try that one and check how many symbols/samples it
> takes to
> >> settle.
> >>
> >> Just go through the papers I mentioned and that idea is easy to
> implement
> >> to do coarse synchronization during fast burst transmissions.
> >>
> >>
> >> ---
> >> Regards
> >> Sreeraj Rajendran
> >> http://home.iitb.ac.in/~rsreeraj
> >>
> >> 
> >> From: Alex Zhang 
> >> To: Sreeraj Rajendran 
> >> Sent: Thursday, 7 March 2013 10:24 PM
> >>
> >> Subject: Re: [Discuss-gnuradio] Very low packet loss rate for the
> >> discontinuous BPSK communications- the analysis and looking for solution
> >>
> >> Dear Sreeraj,
> >>
> >> You mentioned the openloop synch algorithms. Are they refered to the
> >> preamble based carrier recovery?
> >>
> >> Thanks
> >>
> >>
> >> On Mon, Mar 4, 2013 at 8:03 AM, Sreeraj Rajendran
> >>  wrote:
> >>
> >> Alex,
> >>
> >> If Adeel's solution is not meeting your burst transmission specs, you
> can
> >> try implementing some fast openloop synchro algorithms given in
> [1],[2]. You
> >> could look into some data aided schemes too, though I haven't tried
> those
> >> yet.
> >>
> >>
> >> [1] Digital Communication Receivers, Heinrich Meyr, Section 8.2.2
> >> [2] Two Frequency Estimation Schemes Operating Independently of Timing
> >> Information, Ferdinand Classen and Heinrich Meyr
> >>
> >> ---
> >> Regards
> >> Sreeraj Rajendran
> >> http://home.iitb.ac.in/~rsreeraj
> >>
> >> ____
> >> From: Adeel Anwar 
> >> To: Alex Zhang 
> >> Cc: discuss-gnuradio@gnu.org
> >> Sent: Monday, 4 March 2013 5:51 PM
> >> Subject: Re: [Discuss-gnuradio] Very low packet loss rate for the
> >> discontinuous BPSK communications- the analysis and looking for solution
> >>
> >> Alex,
> >>
> >> 1: U can try adjusting the synchronization loops bandwidth (Phase/Timing
> >> etc) see PFB_Timing documentation
> >> 2: Try reducing the receiver gain (for a constant tx-amplitude/gain) or
> >> reduce transmission amplitude/gain (for constant rx gain)
> >>
> >> -Adeel
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Sat, Mar 2, 2013 at 10:21 AM, Alex Zhang 
> >> wrote:
> >>
> >> I think you may rarely get the correct packet with pktno = 0, in
> >> continuous mode, as my guess. Your received correct packet starts from
> pktno
> >> = 1.
> >> Could you also try the discontinuous mode for the BPSK communications?
> >>
> >> My question is actually a problem that how to implement a more reliable
> >> BPSK mod/demod in burst mode. The current bpsk example in GNURadio does
> not
> >> work well in burst 

Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Alex Zhang]

Hi Sreeraj and Tom,

For the discontinuous mode, by cutting the freq_bw to below half of the
default value, I found that for differential_bpsk, the packet loss rate can
be improved(from 30% to 70%), but for non-differential bpsk, the
improvement is hard to see. Especially, for non-differential bpsk, I found
that often the whole burst (5 packets) could lost. Maybe, it is due to the
Phase rotation. I am still trying to investigate.



On Thu, Mar 7, 2013 at 11:08 AM, Sreeraj Rajendran
wrote:

> Alex,
>
> That one is non data aided(no preamble) frequency syncronization. As Tom
> mentioned FLL must be the slowest one in the three.
>
> Did you try adjusting loop bandwidth?. There is an example_fll example in
> gr-digial. Just try that one and check how many symbols/samples it takes to
> settle.
>
> Just go through the papers I mentioned and that idea is easy to implement
> to do coarse synchronization during fast burst transmissions.
>
>
> ---
> Regards
> Sreeraj Rajendran
> http://home.iitb.ac.in/~rsreeraj
>
>   --
> *From:* Alex Zhang 
> *To:* Sreeraj Rajendran 
> *Sent:* Thursday, 7 March 2013 10:24 PM
>
> *Subject:* Re: [Discuss-gnuradio] Very low packet loss rate for the
> discontinuous BPSK communications- the analysis and looking for solution
>
> Dear Sreeraj,
>
> You mentioned the openloop synch algorithms. Are they refered to the
> preamble based carrier recovery?
>
> Thanks
>
>
> On Mon, Mar 4, 2013 at 8:03 AM, Sreeraj Rajendran  > wrote:
>
> Alex,
>
> If Adeel's solution is not meeting your burst transmission specs, you can
> try implementing some fast openloop synchro algorithms given in [1],[2].
> You could look into some data aided schemes too, though I haven't tried
> those yet.
>
>
> [1] Digital Communication Receivers, Heinrich Meyr, Section 8.2.2
> [2] Two Frequency Estimation Schemes Operating Independently of Timing
> Information, Ferdinand Classen and Heinrich Meyr
>
> ---
> Regards
> Sreeraj Rajendran
> http://home.iitb.ac.in/~rsreeraj
>
>   --
> *From:* Adeel Anwar 
> *To:* Alex Zhang 
> *Cc:* discuss-gnuradio@gnu.org
> *Sent:* Monday, 4 March 2013 5:51 PM
> *Subject:* Re: [Discuss-gnuradio] Very low packet loss rate for the
> discontinuous BPSK communications- the analysis and looking for solution
>
> Alex,
>
> 1: U can try adjusting the synchronization loops bandwidth (Phase/Timing
> etc) see PFB_Timing documentation
> 2: Try reducing the receiver gain (for a constant tx-amplitude/gain) or
> reduce transmission amplitude/gain (for constant rx gain)
>
> -Adeel
>
>
>
>
>
>
> On Sat, Mar 2, 2013 at 10:21 AM, Alex Zhang wrote:
>
> I think you may rarely get the correct packet with pktno = 0, in
> continuous mode, as my guess. Your received correct packet starts from
> pktno = 1.
> Could you also try the discontinuous mode for the BPSK communications?
>
> My question is actually a problem that how to implement a more reliable
> BPSK mod/demod in burst mode. The current bpsk example in GNURadio does not
> work well in burst mode.
>
>
> On Fri, Mar 1, 2013 at 11:12 PM, Manu T S  wrote:
>
> Alex,
>
> If it was about loosing sync, we would mostly loose the first packet even
> if we are sending in continuous mode. I personally face no such issues.
>
>
> On Sat, Mar 2, 2013 at 3:25 AM, Alex Zhang wrote:
>
> Seems no one can shed a light on this topic?
>
>
> On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang wrote:
>
> Hello,
>
> In the current gr-digital/narrowband, I am using the benchmark_tx.py and
> rx.py to test the bpsk communications.
> It is found that the packet loss rate is very high (70% loss) in
> discontinuous mode where every 5 packets are in a burst. But in continuous
> mode, the paket loss rate is less than 10% for the same point to point
> link.
>
> I captured the waveform data. From the observed result, it seems that for
> each burst (5 packet), the bpsk receiver needs to re-do the frequency/time
> sync. This will directly causes that the first packet of each burst will
> definitely be crashed. Also, some burst can not be demodulated correctly at
> all. For the same reason, even in the continuous mode, the very first
> packet is also crashed at the receiver.
>
> I have tried  to add very long preamble for each packet to ensure the data
> part of the packet can be received in well sync status. But the result is
> not very good.
>
> Before I get further investigation on the solutions, just wondering if any
> ideas or existing work within this community.
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
>
>
>
>

Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Alex Zhang]

Besides the tips mentioned in the previous mails, I am wondering if the
carrier recovery can performed by adding proper preamble fore the burst
mode bpsk communication.
Several books mentioned that but did not provide more details;

for example:

Radio System Design for Telecommunication  By Roger L. Freeman
page 417.

Satellite Communication
 By Dharma Raj Cheruku
page 138

Especially the latter book, a preamble with 352 bits are used as carrier
recovery, which is much faster than the my current FLL.
I am wondering if any guy who have similar implementation.


On Wed, Mar 6, 2013 at 7:08 AM, Tom Rondeau  wrote:

> On Wed, Mar 6, 2013 at 6:42 AM, Sreeraj Rajendran
>  wrote:
> >
> >>>I don't believe this problem can be solved by adjusting the loop
> >>> bandwidth.
> >
> > Acquisition time is roughly inversely proportional to loop_bw and error
> > variance is proportional to loop_bw. So there is always a tradeoff
> between
> > acquisition time and tracking performance. You should try adjusting
> loop_bw
> > (http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html).
> >
> >>>Applying faster tracking algorithm may solve this problem, but I think
> it
> >>> takes long time to develop for a new guy.
> >
> > If you have a good understanding of the algorithm, its really easy to
> > prototype the alogorithm in GRC or  by using gnuradio python-block coding
> > support. "gr_modtool" is always there to make block coding easier.
> >
> > -Sreeraj
>
>
> Also hand tune to make sure the frequencies of the transmitter and
> receiver are as close as you can get them. The slowest loop in this
> chain is the frequency lock loop, so overcome that by hand and see
> what happens.
>
> Tom
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Alex Zhang]

Thanks you all.
I will try to adjust th loop_bw in the fll firstly to see what happened.

And I am not understanding the function advance_loop(error) well:

void
gri_control_loop::advance_loop(float error)
{
  d_freq = d_freq + d_beta * error;
  d_phase = d_phase + d_freq + d_alpha * error;
}

I am not clear why d_freq and d_phase are updated in this way. Is the
d_freq the frequency offset estimate every step?

According to the
http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html , i
have a rough picture on this, but still confused why d_freq is only
dependent on d_beta.

The other question is: Is it possible to turn off the loop when there is no
input signal (only noise) and turn on the loop when signal is detected?
If possible, how to update hte d_freq and d_phase?




On Wed, Mar 6, 2013 at 7:08 AM, Tom Rondeau  wrote:

> On Wed, Mar 6, 2013 at 6:42 AM, Sreeraj Rajendran
>  wrote:
> >
> >>>I don't believe this problem can be solved by adjusting the loop
> >>> bandwidth.
> >
> > Acquisition time is roughly inversely proportional to loop_bw and error
> > variance is proportional to loop_bw. So there is always a tradeoff
> between
> > acquisition time and tracking performance. You should try adjusting
> loop_bw
> > (http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html).
> >
> >>>Applying faster tracking algorithm may solve this problem, but I think
> it
> >>> takes long time to develop for a new guy.
> >
> > If you have a good understanding of the algorithm, its really easy to
> > prototype the alogorithm in GRC or  by using gnuradio python-block coding
> > support. "gr_modtool" is always there to make block coding easier.
> >
> > -Sreeraj
>
>
> Also hand tune to make sure the frequencies of the transmitter and
> receiver are as close as you can get them. The slowest loop in this
> chain is the frequency lock loop, so overcome that by hand and see
> what happens.
>
> Tom
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Alex Zhang]

I don't believe this problem can be solved by adjusting the loop bandwidth.
Applying faster tracking algorithm may solve this problem, but I think it
takes long time to develop for a new guy.


On Wed, Mar 6, 2013 at 3:44 AM, Jawad Seddar  wrote:

> Hello,
>
> I am getting the same problem you described here i.e very high packet loss
> in discontinuous mode (first and last packet received with ok=False).
>
> Could you please elaborate on how to adjust the synchronisation loops
> bandwidth?
> I have tried adjusting the --timing-bw and --phase-bw parameters on the
> benchmark-rx example, but I don't know if that is what you were talking
> about.
>
>
> *From:* Adeel Anwar 
>> *To:* Alex Zhang 
>> *Cc:* address@hidden
>> *Sent:* Monday, 4 March 2013 5:51 PM
>> *Subject:* Re: [Discuss-gnuradio] Very low packet loss rate for the
>> discontinuous BPSK communications- the analysis and looking for solution
>>
>> Alex,
>>
>> 1: U can try adjusting the synchronization loops bandwidth (Phase/Timing
>> etc) see PFB_Timing documentation
>> 2: Try reducing the receiver gain (for a constant tx-amplitude/gain) or
>> reduce transmission amplitude/gain (for constant rx gain)
>>
>> -Adeel
>>
>>
>>
>>
>>
>>
>> On Sat, Mar 2, 2013 at 10:21 AM, Alex Zhang  wrote:
>>
>> I think you may rarely get the correct packet with pktno = 0, in
>> continuous mode, as my guess. Your received correct packet starts from
>> pktno = 1.
>> Could you also try the discontinuous mode for the BPSK communications?
>>
>> My question is actually a problem that how to implement a more reliable
>> BPSK mod/demod in burst mode. The current bpsk example in GNURadio does not
>> work well in burst mode.
>>
>>
>> On Fri, Mar 1, 2013 at 11:12 PM, Manu T S  wrote:
>>
>> Alex,
>>
>> If it was about loosing sync, we would mostly loose the first packet even
>> if we are sending in continuous mode. I personally face no such issues.
>>
>>
>> On Sat, Mar 2, 2013 at 3:25 AM, Alex Zhang  wrote:
>>
>> Seems no one can shed a light on this topic?
>>
>>
>> On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang  wrote:
>>
>> Hello,
>>
>> In the current gr-digital/narrowband, I am using the benchmark_tx.py and
>> rx.py to test the bpsk communications.
>> It is found that the packet loss rate is very high (70% loss) in
>> discontinuous mode where every 5 packets are in a burst. But in continuous
>> mode, the paket loss rate is less than 10% for the same point to point
>> link.
>>
>> I captured the waveform data. From the observed result, it seems that for
>> each burst (5 packet), the bpsk receiver needs to re-do the frequency/time
>> sync. This will directly causes that the first packet of each burst will
>> definitely be crashed. Also, some burst can not be demodulated correctly at
>> all. For the same reason, even in the continuous mode, the very first
>> packet is also crashed at the receiver.
>>
>> I have tried  to add very long preamble for each packet to ensure the
>> data part of the packet can be received in well sync status. But the result
>> is not very good.
>>
>> Before I get further investigation on the solutions, just wondering if
>> any ideas or existing work within this community.
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Questions about tdma_engine.py

[Alex Zhang]

hello John,

I am wondering, in future,  if the receiver will also work in a tdma manner
at the waveform level,i.e, the demodulation can be done within specified
time slot. One of the benefits is that the computing on the receiver can be
decreased significant.

Thanks.


On Sun, Mar 3, 2013 at 8:50 PM, John Malsbury wrote:

> You are correct.  The demodulated will demodulate continuous.  The receive
> samples are routed to the TDMA engine for timing information of the
> transmissions.
>
> -John
>
>
> On Sun, Mar 3, 2013 at 5:48 PM, Gong Zhang  wrote:
>
>> Hi,
>> I have read the file tdma_engine.py in PreCog.It seems they deal with
>> data and update local time according to the time tags.But how can we
>> demodulated the signal from antenna in the start without knowing the
>> time.Is this imply we can only transmission at the fixed frequency?I
>> appreciate any tips.
>> Thank you.
>>
>> ___
>> 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
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Alex Zhang]

I think you may rarely get the correct packet with pktno = 0, in continuous
mode, as my guess. Your received correct packet starts from pktno = 1.
Could you also try the discontinuous mode for the BPSK communications?

My question is actually a problem that how to implement a more reliable
BPSK mod/demod in burst mode. The current bpsk example in GNURadio does not
work well in burst mode.


On Fri, Mar 1, 2013 at 11:12 PM, Manu T S  wrote:

> Alex,
>
> If it was about loosing sync, we would mostly loose the first packet even
> if we are sending in continuous mode. I personally face no such issues.
>
>
> On Sat, Mar 2, 2013 at 3:25 AM, Alex Zhang wrote:
>
>> Seems no one can shed a light on this topic?
>>
>>
>> On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang wrote:
>>
>>> Hello,
>>>
>>> In the current gr-digital/narrowband, I am using the benchmark_tx.py and
>>> rx.py to test the bpsk communications.
>>> It is found that the packet loss rate is very high (70% loss) in
>>> discontinuous mode where every 5 packets are in a burst. But in continuous
>>> mode, the paket loss rate is less than 10% for the same point to point
>>> link.
>>>
>>> I captured the waveform data. From the observed result, it seems that
>>> for each burst (5 packet), the bpsk receiver needs to re-do the
>>> frequency/time sync. This will directly causes that the first packet of
>>> each burst will definitely be crashed. Also, some burst can not be
>>> demodulated correctly at all. For the same reason, even in the continuous
>>> mode, the very first packet is also crashed at the receiver.
>>>
>>> I have tried  to add very long preamble for each packet to ensure the
>>> data part of the packet can be received in well sync status. But the result
>>> is not very good.
>>>
>>> Before I get further investigation on the solutions, just wondering if
>>> any ideas or existing work within this community.
>>>
>>> --
>>>
>>> Alex,
>>> *Dreams can come true – just believe.*
>>>
>>
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Manu T S
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Alex Zhang]

Seems no one can shed a light on this topic?


On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang wrote:

> Hello,
>
> In the current gr-digital/narrowband, I am using the benchmark_tx.py and
> rx.py to test the bpsk communications.
> It is found that the packet loss rate is very high (70% loss) in
> discontinuous mode where every 5 packets are in a burst. But in continuous
> mode, the paket loss rate is less than 10% for the same point to point
> link.
>
> I captured the waveform data. From the observed result, it seems that for
> each burst (5 packet), the bpsk receiver needs to re-do the frequency/time
> sync. This will directly causes that the first packet of each burst will
> definitely be crashed. Also, some burst can not be demodulated correctly at
> all. For the same reason, even in the continuous mode, the very first
> packet is also crashed at the receiver.
>
> I have tried  to add very long preamble for each packet to ensure the data
> part of the packet can be received in well sync status. But the result is
> not very good.
>
> Before I get further investigation on the solutions, just wondering if any
> ideas or existing work within this community.
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution

[Alex Zhang]

Hello,

In the current gr-digital/narrowband, I am using the benchmark_tx.py and
rx.py to test the bpsk communications.
It is found that the packet loss rate is very high (70% loss) in
discontinuous mode where every 5 packets are in a burst. But in continuous
mode, the paket loss rate is less than 10% for the same point to point
link.

I captured the waveform data. From the observed result, it seems that for
each burst (5 packet), the bpsk receiver needs to re-do the frequency/time
sync. This will directly causes that the first packet of each burst will
definitely be crashed. Also, some burst can not be demodulated correctly at
all. For the same reason, even in the continuous mode, the very first
packet is also crashed at the receiver.

I have tried  to add very long preamble for each packet to ensure the data
part of the packet can be received in well sync status. But the result is
not very good.

Before I get further investigation on the solutions, just wondering if any
ideas or existing work within this community.

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Google Summer of Code 2013

[Alex Zhang]

It's cool! Thanks!


On Thu, Feb 28, 2013 at 11:51 AM, Martin Braun (CEL)
wrote:

> On Thu, Feb 28, 2013 at 11:38:40AM -0600, Alex Zhang wrote:
> > For me, I am very interested in that is there any open project to
> improve the
> > data rate and packet loss for the GNURadio based OFDM?
> >
> > Some guys claimed that the LTE standards are implemented with USRP and
> PC by
> > SIMD programming. But their code are not open.
> >
> > If GNURadio based OFDM can support high data rate as LTE, the PC based
> access
> > point or LTE base station can be used for a wide range of research,
> especially
> > the real large scale network.
>
> Hi Alex,
>
> perhaps you might be interested in two ongoing projects:
>
> https://github.com/benreynwar/gnuradio/tree/ofdm
> is a rehaul of the current OFDM implementation.
>
> https://github.com/kit-cel/gr-lte
> is an LTE receiver for the broadcast channels, although pretty early in
> it's development.
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Google Summer of Code 2013

[Alex Zhang]

For me, I am very interested in that is there any open project to improve
the data rate and packet loss for the GNURadio based OFDM?
Some guys claimed that the LTE standards are implemented with USRP and PC
by SIMD programming. But their code are not open.

If GNURadio based OFDM can support high data rate as LTE, the PC based
access point or LTE base station can be used for a wide range of research,
especially the real large scale network.


On Wed, Feb 27, 2013 at 11:39 AM, Martin Braun (CEL)
wrote:

> Ideas, ideas, ideas!
>
> Everyone, we need ideas.
> The GSoC application deadline is coming closer, and we still are lacking
> some ideas.
>
> So what cool feature of GNU Radio are *you* missing?
>
> Head over here, and write them down:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC
>
> At this point, any random idea is OK. Also, you're not signing up for
> anything if you post an idea.
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] What are the actual meaning of slot_interval, guard_interval, lead_limit in TDMA engine of Pre-Cog

[Alex Zhang]

Hi John,

I am using the TDMA engine of the Pre-Cog, and investigating the code. For
some parameters in the initlization of the TDMA engine, I am wondering if i
understand correctly:

self.initial_slot = initial_slot
self.slot_interval = slot_interval
self.guard_interval = guard_interval
self.num_slots = num_slots
self.lead_limit = lead_limit

Could you shed a light on them, especially the lead_limit.

Thanks very much.


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Import error of grextras, undefined symbol

[Alex Zhang]

Maybe it is due to my own building which is very obsolete. I will try to
reinstall the latest version of gnuradio and grextras.


On Tue, Feb 19, 2013 at 5:35 PM, Alex Zhang  wrote:

> It does not work after the modification and rebuilding of the grextras.
>
> My modification:
>
> diff --git a/swig/CMakeLists.txt b/swig/CMakeLists.txt
> index 129d789..42732a3 100644
> --- a/swig/CMakeLists.txt
> +++ b/swig/CMakeLists.txt
> @@ -58,7 +58,7 @@ foreach(incdir ${GRUEL_INCLUDE_DIRS})
>  list(APPEND GR_SWIG_INCLUDE_DIRS ${incdir}/gruel/swig)
>  endforeach(incdir)
>
> -set(GR_SWIG_LIBRARIES gnuradio-extras)
> +list(APPEND GR_SWIG_LIBRARIES gnuradio-extras ${GNURADIO_CORE_LIBRARIES}
> ${G
>  set(GR_SWIG_DOC_FILE ${CMAKE_CURRENT_BINARY_DIR}/extras_swig_doc.i)
>  set(GR_SWIG_DOC_DIRS
> ${CMAKE_CURRENT_SOURCE_DIR}/../include/gnuradio/extras)
>
>
> On Tue, Feb 19, 2013 at 5:06 PM, Josh Blum  wrote:
>
>>
>>
>> On 02/19/2013 04:59 PM, Alex Zhang wrote:
>> > Hi,
>> >
>> > I believe some other guys met this problem before, but I did not find
>> the
>> > final solution expressed clearly.
>> >
>> > After I installed the gnuradio, grextras, then in my python code which
>> trys
>> > to import the extras_swig  like
>> >
>> > import gnuradio.extras as gr_extras
>> >   File
>> > "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py",
>> line
>> > 20, in 
>> > from extras_swig import *
>> >   File
>> > "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
>> > line 26, in 
>> > _extras_swig = swig_import_helper()
>> >   File
>> > "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
>> > line 22, in swig_import_helper
>> > _mod = imp.load_module('_extras_swig', fp, pathname, description)
>> > ImportError: /usr/local/lib/libgnuradio-extras.so: undefined symbol:
>> > _ZN15gr_msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES4_
>> >
>> >
>> > Can any one shed a light on it?
>>
>> Maybe its missing a library to link w/
>>
>> Can you try this and let me know?
>>
>> http://pastebin.com/t5GL5Z6G
>>
>> -josh
>> >
>> >
>> >
>> > ___
>> > 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
>>
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Import error of grextras, undefined symbol

[Alex Zhang]

It does not work after the modification and rebuilding of the grextras.

My modification:

diff --git a/swig/CMakeLists.txt b/swig/CMakeLists.txt
index 129d789..42732a3 100644
--- a/swig/CMakeLists.txt
+++ b/swig/CMakeLists.txt
@@ -58,7 +58,7 @@ foreach(incdir ${GRUEL_INCLUDE_DIRS})
 list(APPEND GR_SWIG_INCLUDE_DIRS ${incdir}/gruel/swig)
 endforeach(incdir)

-set(GR_SWIG_LIBRARIES gnuradio-extras)
+list(APPEND GR_SWIG_LIBRARIES gnuradio-extras ${GNURADIO_CORE_LIBRARIES}
${G
 set(GR_SWIG_DOC_FILE ${CMAKE_CURRENT_BINARY_DIR}/extras_swig_doc.i)
 set(GR_SWIG_DOC_DIRS
${CMAKE_CURRENT_SOURCE_DIR}/../include/gnuradio/extras)


On Tue, Feb 19, 2013 at 5:06 PM, Josh Blum  wrote:

>
>
> On 02/19/2013 04:59 PM, Alex Zhang wrote:
> > Hi,
> >
> > I believe some other guys met this problem before, but I did not find the
> > final solution expressed clearly.
> >
> > After I installed the gnuradio, grextras, then in my python code which
> trys
> > to import the extras_swig  like
> >
> > import gnuradio.extras as gr_extras
> >   File
> > "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py",
> line
> > 20, in 
> > from extras_swig import *
> >   File
> > "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
> > line 26, in 
> > _extras_swig = swig_import_helper()
> >   File
> > "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
> > line 22, in swig_import_helper
> > _mod = imp.load_module('_extras_swig', fp, pathname, description)
> > ImportError: /usr/local/lib/libgnuradio-extras.so: undefined symbol:
> > _ZN15gr_msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES4_
> >
> >
> > Can any one shed a light on it?
>
> Maybe its missing a library to link w/
>
> Can you try this and let me know?
>
> http://pastebin.com/t5GL5Z6G
>
> -josh
> >
> >
> >
> > ___
> > 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
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Import error of grextras, undefined symbol

[Alex Zhang]

Hi,

I believe some other guys met this problem before, but I did not find the
final solution expressed clearly.

After I installed the gnuradio, grextras, then in my python code which trys
to import the extras_swig  like

import gnuradio.extras as gr_extras
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/extras/__init__.py", line
20, in 
from extras_swig import *
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
line 26, in 
_extras_swig = swig_import_helper()
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
line 22, in swig_import_helper
_mod = imp.load_module('_extras_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-extras.so: undefined symbol:
_ZN15gr_msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES4_


Can any one shed a light on it?

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Echo Cancellation for USRP?

[Alex Zhang]

Hello Gurus,

My duplex system is using only one frequency but different time slot to let
two USRP exchange data. But from the observed receiving waveforms, I found
that the received signal is very high and causes the jitter if the receiver
keeps receiving its own transmitted signal within its own time slot. This
jitter could impact the subsequent time slot for other transmitter, by a
tail.
I want to add something like echo cancellation to remove this side-effect.
Before that I am wondering if any has done the similar thing. Also,  I
don't think the pure software method can solve this problem. Do we have any
hardware support for this transmitting close loop issue?

Best Regards,

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pre-cog repo is down?

[Alex Zhang]

But the wiki is down.. 404.


On Mon, Feb 4, 2013 at 9:47 PM, John Malsbury wrote:

> https://github.com/jmalsbury/pre-cog
>
>
>
>
> On Mon, Feb 4, 2013 at 7:45 PM, Karan Talasila wrote:
>
>> Hi,
>>   Even I am not able to open it. even the wiki of pre-cog isn't
>> opening.
>>
>>
>> On Mon, Feb 4, 2013 at 10:42 PM, John Malsbury 
>> wrote:
>>
>>> https://github.com/jmalsbury/pre-cog
>>>
>>> On Mon, Feb 4, 2013 at 7:41 PM, George Sklivanitis <
>>> george.sklivani...@gmail.com> wrote:
>>>
 Hello guys,

 Is https://github.com/buoyboy/pre-cog down
 or I am the only one not being able to have access?

 -George

 --
 Sklivanitis Georgios
 Postgraduate Student


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


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How the upstream block of TDMA engine get the current time of the network

[Alex Zhang]

Maybe I have misunderstanding on tdma_engine. Does it only handle the
incoming samples from the usrp source, which means rx samples? I really
want to figure out how the tdma transmitter works.


On Mon, Feb 4, 2013 at 9:45 AM, Josh Blum  wrote:

>
>
> On 02/04/2013 01:32 AM, Alex Zhang wrote:
> > Previously, the pre-cog introduced a simple implementation of TDMA:
> > http://gnuradio.4.n7.nabble.com/Introduction-to-Pre-Cog-td37906.html
> >
> > I read roughly the code in the tdma_engine.py.
> > For the transmitter, it seems that this tdma_engine works like a throttle
> > to send the messages to the downstreams only when the time_update is
>  later
> > than the time_transmit_start.
> > And these time are computed based on the tags in the incoming items
> > inserted by upstream block.
> > My question is that, where does the upstream block get the correct time?
> I
> > know that the usrp_sink can get_time_now but it is on the very
> downstream,
> > and it is different block which means different thread.
> >
> > If my question is not clear, please give your comments.
>
>
> time indication should be coming from the usrp source block. the rx
> samples are timestamped, which allows the engine to line up with a time
> slot
>
> -josh
>
> >
> > Thanks.
> >
> >
> >
> > ___
> > 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
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How the upstream block of TDMA engine get the current time of the network

[Alex Zhang]

Hi John,

Thanks for these examples. I also read that yesterday.
Just want to confirm that:
1. TDMA engine is only responsible for extract the time from the rx samples
from the USRP resource.
2. The burst gate block schedules the time for the tx samples.

Are they correct?


On Mon, Feb 4, 2013 at 11:20 AM, John Malsbury wrote:

> Alex,
>
> I'm on a machine without GNU Radio installed, so I have to confirm that
> I'm actually sending the right examples, but the attahced files may add
> some insight.
>
> The examples were intended for demonstration of the timed streaming
> features and currently rely on a 1 PPS signal to provide synchronization
> across multiple units.
>
> -John
>
>
>
>
> On Mon, Feb 4, 2013 at 8:33 AM, Alex Zhang wrote:
>
>> Hi Josh,
>>
>> Sorry the unclear question. Actually I am asking how the transmitter
>> organize the TX samples to the specified time slot..
>>
>>
>> On Mon, Feb 4, 2013 at 9:45 AM, Josh Blum  wrote:
>>
>>>
>>>
>>> On 02/04/2013 01:32 AM, Alex Zhang wrote:
>>> > Previously, the pre-cog introduced a simple implementation of TDMA:
>>> > http://gnuradio.4.n7.nabble.com/Introduction-to-Pre-Cog-td37906.html
>>> >
>>> > I read roughly the code in the tdma_engine.py.
>>> > For the transmitter, it seems that this tdma_engine works like a
>>> throttle
>>> > to send the messages to the downstreams only when the time_update is
>>>  later
>>> > than the time_transmit_start.
>>> > And these time are computed based on the tags in the incoming items
>>> > inserted by upstream block.
>>> > My question is that, where does the upstream block get the correct
>>> time? I
>>> > know that the usrp_sink can get_time_now but it is on the very
>>> downstream,
>>> > and it is different block which means different thread.
>>> >
>>> > If my question is not clear, please give your comments.
>>>
>>>
>>> time indication should be coming from the usrp source block. the rx
>>> samples are timestamped, which allows the engine to line up with a time
>>> slot
>>>
>>> -josh
>>>
>>> >
>>> > Thanks.
>>> >
>>> >
>>> >
>>> > ___
>>> > 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
>>>
>>
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How the upstream block of TDMA engine get the current time of the network

[Alex Zhang]

Hi Josh,

Sorry the unclear question. Actually I am asking how the transmitter
organize the TX samples to the specified time slot..


On Mon, Feb 4, 2013 at 9:45 AM, Josh Blum  wrote:

>
>
> On 02/04/2013 01:32 AM, Alex Zhang wrote:
> > Previously, the pre-cog introduced a simple implementation of TDMA:
> > http://gnuradio.4.n7.nabble.com/Introduction-to-Pre-Cog-td37906.html
> >
> > I read roughly the code in the tdma_engine.py.
> > For the transmitter, it seems that this tdma_engine works like a throttle
> > to send the messages to the downstreams only when the time_update is
>  later
> > than the time_transmit_start.
> > And these time are computed based on the tags in the incoming items
> > inserted by upstream block.
> > My question is that, where does the upstream block get the correct time?
> I
> > know that the usrp_sink can get_time_now but it is on the very
> downstream,
> > and it is different block which means different thread.
> >
> > If my question is not clear, please give your comments.
>
>
> time indication should be coming from the usrp source block. the rx
> samples are timestamped, which allows the engine to line up with a time
> slot
>
> -josh
>
> >
> > Thanks.
> >
> >
> >
> > ___
> > 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
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How the upstream block of TDMA engine get the current time of the network

[Alex Zhang]

Previously, the pre-cog introduced a simple implementation of TDMA:
http://gnuradio.4.n7.nabble.com/Introduction-to-Pre-Cog-td37906.html

I read roughly the code in the tdma_engine.py.
For the transmitter, it seems that this tdma_engine works like a throttle
to send the messages to the downstreams only when the time_update is  later
than the time_transmit_start.
And these time are computed based on the tags in the incoming items
inserted by upstream block.
My question is that, where does the upstream block get the correct time? I
know that the usrp_sink can get_time_now but it is on the very downstream,
and it is different block which means different thread.

If my question is not clear, please give your comments.

Thanks.

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Benchmark Duplex

[Alex Zhang]

Try use different frequency for transmitter and receiver.


On Thu, Jan 31, 2013 at 8:51 PM, Dong Wang  wrote:

> Hi
>
> When I try to establish the duplex comunication between two USRPs, I found
> that if I put the code A infront of code B, only the transmitter works, but
> if I put code B infront of code A, only receiver works.
> Could anyone tells me the reason?
> Thanks a lot!
>
>
> code A:
> self.source = uhd_receiver(options.args, symbol_rate,
>options.samples_per_symbol,
>options.rx_freq, options.rx_gain,
>options.spec, options.antenna,
>options.verbose)
>
>
> code B:
> self.sink = uhd_transmitter(options.args, symbol_rate,
> options.samples_per_symbol,
> options.tx_freq, options.tx_gain,
> options.spec, options.antenna,
> options.verbose)
> Best regards!
>
> Dong Wang
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] About FLL and phase tracking error in narrow band domodulation

[Alex Zhang]

Hello,

I am reading the code for frequency correction in the demodulation chain
for the narrow band like PSK, GMSK, etc.

In the gnuradio/gr-digital/python/generic_mod_demod.py, two blocks contains
the code related to the frequency offset correction.

1. digital.fll_band_edge_cc
  I am not familiar with the algorithm employed in this frequency loop
locking block. Is there any direct reference for this block, such as paper
or documentation?

2. digital.constellation_receiver_cb
 It has a member function to update the phase and frequecy of the incoming
samples, digital_constellation_receiver_cb::phase_error_tracking()
Is there any reference for me to understand it more easily. Especially,
this member function calls
void
gri_control_loop::advance_loop(float error)
{
  d_freq = d_freq + d_beta * error;
  d_phase = d_phase + d_freq + d_alpha * error;
}

where the d_beta  and d_alpha is updated in
void
gri_control_loop::update_gains()
{
  float denom = (1.0 + 2.0*d_damping*d_loop_bw + d_loop_bw*d_loop_bw);
  d_alpha = (4*d_damping*d_loop_bw) / denom;
  d_beta = (4*d_loop_bw*d_loop_bw) / denom;
}

I did not find any explanation for these two part of codes.
Appreciate any helps.

Thanks

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE soft modem from Icera

[Alex Zhang]

Can anybody explain the difference between this softmodem and other
existing wireless baseband programmable processors?
My understanding is that, also as Marcus mentioned, it provides more
flexibility by this array of special CPUs instead of the prefixed
functions/blocks, within this chip. Otherwise, it won't bring big novelty.

As to the ADC/DAC and RF part, maybe we need to wait for the whole SDR
 solution to be unveiled.


On Mon, Jan 7, 2013 at 11:29 AM, Marcus D. Leech  wrote:

> I don't have high hopes for this specific chip - I guess the IC will be
>> hard to buy and the modem feature on built devices will hard to hack,
>> lacking source and documentation for its drivers, just as Android devices
>> are hard for cyanogenmod developers to hack with.
>>
>> But these news do give some hope, the hope that more accessible high-end
>> ARMs chips like TI's and Freescales' will follow up and incorporate these
>> features in the future. Indeed, I am already working on a beaglebone-based
>> SDR and this would be great.
>>
>>  It looks to me like this SoftModem chip is just an array of speciality
> CPUs.  What I want to see is details of ADC/DAC and the RF-to-baseband
>   transceivers -- those aren't part of the same chip.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio based papers on channel sounding and TDMA

[Alex Zhang]

Hi Nazmul,

Seem your second paper can not downloadable?

Thanks


On Tue, Nov 27, 2012 at 11:55 PM, Nazmul Islam
wrote:

> Hello,
>
> I would like to announce two GNUradio based papers that I
> published/submitted a few months ago. The full reference of the papers are
> given below:
>
> 1. Muhammad Nazmul Islam, Byoung-Jo J. Kim, Paul Henry, Eric Rozner, "A
> Wireless Channel Sounding System for Rapid Propagation 
> Measurements",
> submitted to International Conference on Communications 2013. (
> http://arxiv.org/abs/1211.4940)
>
> 2. Muhammad Nazmul Islam, Shantharam Balasubramanian, Narayan B.
> Mandayam, Ivan Seskar, Sastry Kompella, "Implementation of Distributed
> Time Exchange Based Cooperative Forwarding",
> published in Military Communications Conference 2012
> (http://arxiv.org/abs/1210.5424)
>
> I also want to address a particular point about my channel sounding
> experiments. I have seen several channel sounding based posts in the
> mailing list where the authors talk about the speed bottlenecks of Gigabit
> ethernet cable. Basically, the speed bottleneck of the ethernet cable or
> the computer limits the temporal resolution of the sliding correlator based
> channel sounding. For example, if you transmit at 10 Mega Symbol/sec, you
> can only find multipath components at 100 ns, 200 ns, etc. However, this
> problem can be bypassed by using frequency domain channel sounding. One can
> send a frequency hopping sequence, determine the frequency domain channel
> characteristics and then find the channel impulse response through inverse
> FFT. In this case, the temporal resolution of the multipath components
> won't depend on the symbol rate. The paper #1 talks about both sliding
> correlator and frequency domain channel sounding approaches.
>
> I took the opportunity to add a copy on the academic papers section:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/AcademicPapers.
> Feedback and comments will be very appreciated.
>
> Thanks,
>
> Nazmul
>
>
> --
> Muhammad Nazmul Islam
>
> Graduate Student
> Electrical & Computer Engineering
> Wireless Information & Networking Laboratory
> Rutgers, USA.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] control of noutput_items by the user

[Alex Zhang]

I am not sure it can work or not:

Set the in/out ratio while setting the output multiple, then you can
control the output items number by setting the required input items in the
forecast() of your block.


On Fri, Nov 30, 2012 at 5:51 PM, Zing Yu  wrote:

> Hi All,
>
> As usual, I have a simple question for you guys. I have a custom block for
> which I specify set_output_multiple(N) in the constructor. Then, for each
> call to its work(), I print the parameter noutput_items. As expected,
> noutput_items = N most of the times, but occasionally it comes out as 2N.
> My concern is that I always want noutput_items = N. I know noutput_items
> are assigned by the scheduler and I have a some control over it by means of
> set_output_multiple but I want to have more/full control on it. Is that
> possible? Any suggestions?
>
> Thanks.
> Yu.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python report typeError of argument for my block

[Alex Zhang]

Thanks Josh,

Just found that my C++ interface is using type of uint64_t while I passed
the data of time_t in python. And the python/SWIG cannot convert the time_t
to uint64_t automatically, unlike in C++...

Changed the C++ interface to time_t and make the type conversion within the
C++ code. The constructor works in python now.

But we do need to pay attention when c++ types is not recognized in python,
assuming your suggestion is a solution. I will try this later for possible
case.


On Thu, Nov 15, 2012 at 9:20 PM, Josh Blum  wrote:

>
>
> On 11/15/2012 06:44 PM, Alex Zhang wrote:
> > Hello,
> >
> > I wrote a signal block whose constructor has an argument of type
> > "uint64_t".  But when in python it is constructed, the error is reported
> > as TypeErrorL in method 'myblock', argument 1 of type 'uint64_t'.
> >
> > Then I changed the uint64_t to unsigned long long in my C++ code, but the
> > python still report  TypeError for 'unsigned long long'.
> >
> > I am thinking that SWIG can not recognize the uint64_t and unsigned long
> > long, so I need to do something like type mapping , but not know how to
> do
> > it.
> > Is there any example that I can follow?
> >
>
> It should be possible. Try adding %include  at the top of your
> swig file.
>
> -josh
>
> > Thanks
> >
> >
> >
> > ___
> > 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
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Python report typeError of argument for my block

[Alex Zhang]

Hello,

I wrote a signal block whose constructor has an argument of type
"uint64_t".  But when in python it is constructed, the error is reported
as TypeErrorL in method 'myblock', argument 1 of type 'uint64_t'.

Then I changed the uint64_t to unsigned long long in my C++ code, but the
python still report  TypeError for 'unsigned long long'.

I am thinking that SWIG can not recognize the uint64_t and unsigned long
long, so I need to do something like type mapping , but not know how to do
it.
Is there any example that I can follow?

Thanks

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error "SSE3 instruction set not enabled" when using VOLK

[Alex Zhang]

Thanks Tom and Nick, it works now, by just calling the abstract method name.

On Tue, Oct 23, 2012 at 9:21 AM, Tom Rondeau  wrote:

> On Mon, Oct 22, 2012 at 6:53 PM, Alex Zhang 
> wrote:
> > Hello,
> >
> > I am trying to use the volk_32fc_x2_multiply_conjugate_32fc_a_sse3() in
> my
> > signal processing code. However, when I compile my code, it was told that
> > Error "SSE3 instruction set not enabled" and the intrinsics within this
> VOLK
> > method are not recognized at all.
> > It was told that the -msse3 option is needed in gcc/g++ compilation to
> > enable the support on sse3. But I don't know where I can specify this
> > option. I did not find related content in the CMakelist of other blocks
> who
> > support sse, like some filters.
> >
> > Also, my CPU is Core I7-2600, which is suppose to support  SSE3.
> >
> > Thanks,
> >
> > --
> >
> > Alex,
> > Dreams can come true – just believe.
>
>
> Alex,
>
> VOLK is not intended for you to explicitly call a kernel of a
> particular type. You want to call the abstract verson
> (volk_32fc_x2_multiply_conjugate_32fc_a) and let the VOLK runtime
> decide what the best available proto-kernel is (this is determined
> from your volk_config file after you run volk_profile). That will make
> sure that you are using a proto-kernel that you properly compiled and
> that can run on your processor.
>
> To check more into why SSE3 is not available on your machine, take a
> look at the output of cmake to see what it tells you. You can look to
> see what the value of "have_msse3" is in the CMakeCache.txt file.
>
> During make, you can run 'make VERBOSE=1' to get the full compile
> line, too, where you can see what flags are actually being used by GCC
> when compiling.
>
> Tom
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] VOLK for outer product of two vectors?

[Alex Zhang]

Hi Tom,

My current solution, due to my limited developing time,  is to reuse
the volk_32fc_x2_multiply_conjugate_32fc_a to compute the outer product,
instead of writing a separate outer product method.  It works well.

On Tue, Oct 23, 2012 at 9:15 AM, Tom Rondeau  wrote:

> On Sun, Oct 21, 2012 at 4:08 PM, Alex Zhang 
> wrote:
> > Hi,
> >
> > I looked at the VOLK to find if there are existing method to calculate
> the
> > outer product of two vectors, but found nothing about it.
> > If no, I have to write a SIMD based outer product method by myself.
> >
> > Thanks,
> > --
> >
> > Alex,
> > Dreams can come true – just believe.
>
> Alex,
> I don't believe there is a VOLK kernel that does that. But this is why
> VOLK is designed to be extensible for when you need to write your own.
>
> If you do come up with a new outer product kernel, please consider
> giving it back to the VOLK product.
>
> Thanks,
> Tom
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Error "SSE3 instruction set not enabled" when using VOLK

[Alex Zhang]

Hello,

I am trying to use the volk_32fc_x2_multiply_conjugate_32fc_a_sse3() in my
signal processing code. However, when I compile my code, it was told
that Error "SSE3 instruction set not enabled" and the intrinsics within
this VOLK method are not recognized at all.
It was told that the -msse3 option is needed in gcc/g++ compilation to
enable the support on sse3. But I don't know where I can specify this
option. I did not find related content in the CMakelist of other blocks who
support sse, like some filters.

Also, my CPU is Core I7-2600, which is suppose to support  SSE3.

Thanks,

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] VOLK for outer product of two vectors?

[Alex Zhang]

resend.

On Oct 21, 2012, at 3:08 PM, Alex Zhang  wrote:

> Hi,
> 
> I looked at the VOLK to find if there are existing method to calculate the 
> outer product of two vectors, but found nothing about it.
> If no, I have to write a SIMD based outer product method by myself.
> 
> Thanks,
> -- 
> 
> Alex,
> Dreams can come true – just believe.
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] VOLK for outer product of two vectors?

[Alex Zhang]

Hi,

I looked at the VOLK to find if there are existing method to calculate the
outer product of two vectors, but found nothing about it.
If no, I have to write a SIMD based outer product method by myself.

Thanks,
-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Can the io signatur of the gnuradio blocks be dynamically updated?

[Alex Zhang]

Hi Tom,

There is the other thing I need to confirm:
It looks that the block's output buffer size can not be changed after its
construction, right?

On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau  wrote:

> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang 
> wrote:
> > Let me take an example for my question.
> >
> > For some OFDM blocks, the io signature is determined by the fft length,
> > during the constructing the block. However, sometimes, we need to adjust
> the
> > the fft length dynamically based on some physical environment or
> computing
> > environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart the graph. But you are going to lose samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress: https://github.com/osh/gr-eventstream.
>
> Tom
>
>
> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang 
> wrote:
> >>
> >> Hi,
> >>
> >> I know it may not be possible in the current gnuradio blocks framework,
> >> but I am still curious if it can be done.
> >> When I write a signal processing block, the io signature could be
> >> determined by some parameters. It is ok, if these parameters are fixed.
> But
> >> sometimes, especially in the adaptive system, I need to dynamically
> update
> >> these parameter, which result in the updating of io signature of the
> blocks.
> >> I can make the io_signature to be independent with the dynamic
> parameters,
> >> but it could be more convenient if the io signature can be adapted. Of
> >> course, it is not easy, as the io signature change could impact the
> upstream
> >> and downstream.
> >>
> >> Thanks,
> >>
> >> --
> >>
> >> Alex,
> >> Dreams can come true – just believe.
> >>
> >
> >
> >
> > --
> >
> > Alex,
> > Dreams can come true – just believe.
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Can the io signatur of the gnuradio blocks be dynamically updated?

[Alex Zhang]

Hi Tom, thanks for the response, but I am still have questions regarding
your comments as below inline:

On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau  wrote:

> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang 
> wrote:
> > Let me take an example for my question.
> >
> > For some OFDM blocks, the io signature is determined by the fft length,
> > during the constructing the block. However, sometimes, we need to adjust
> the
> > the fft length dynamically based on some physical environment or
> computing
> > environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart the graph. But you are going to lose samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress: https://github.com/osh/gr-eventstream.
>
>
It seems that the event stream scheduler can only handle finite options for
selection?
This is different with what I am expecting. Sometimes, you don't know the
actual options and the dynamic parameters is computed based on some other
optimization algorithm. Thus I can not pre-configure finite graphs for my
selection, but just adjust the exiting graph with specified parameter.

BTW, maybe my expectation is kind of over-design which brings more risk
than benefits. But from the Software defined radio perspective, the
dynamic/adaptive signal processing chain with expecting flexibility really
deserves  more attention.


> Tom
>
>
> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang 
> wrote:
> >>
> >> Hi,
> >>
> >> I know it may not be possible in the current gnuradio blocks framework,
> >> but I am still curious if it can be done.
> >> When I write a signal processing block, the io signature could be
> >> determined by some parameters. It is ok, if these parameters are fixed.
> But
> >> sometimes, especially in the adaptive system, I need to dynamically
> update
> >> these parameter, which result in the updating of io signature of the
> blocks.
> >> I can make the io_signature to be independent with the dynamic
> parameters,
> >> but it could be more convenient if the io signature can be adapted. Of
> >> course, it is not easy, as the io signature change could impact the
> upstream
> >> and downstream.
> >>
> >> Thanks,
> >>
> >> --
> >>
> >> Alex,
> >> Dreams can come true – just believe.
> >>
> >
> >
> >
> > --
> >
> > Alex,
> > Dreams can come true – just believe.
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Can the io signatur of the gnuradio blocks be dynamically updated?

[Alex Zhang]

On Fri, Oct 12, 2012 at 10:16 AM,  wrote:

> **
>
> On 12 Oct 2012 11:12, Tom Rondeau wrote:
>
> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang  wrote:
>
> Let me take an example for my question. For some OFDM blocks, the io
> signature is determined by the fft length, during the constructing the
> block. However, sometimes, we need to adjust the the fft length dynamically
> based on some physical environment or computing environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart the graph. But you are going to lose samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress: https://github.com/osh/gr-eventstream.
>
>
>
>
>  So, my question is why this is any different than the existing cases of
> FFT and FIR filter blocks -- they have an I/O signature of a
> complex-stream, and internally they "do the right thing" when the filter
> length changes.  I don't immediately see why blocks that conceptually
> "change size" can't just do it internally just like the FFT and FIR filter
> cases.
>
Yes, in functionality, I can do it internally, with I/O signature
independent of the adaptive parameters. I just want to discuss if the
dynamic I/O signature  can be done and to provide the user with another
user mode which looks cleaner. Because, we do have blocks that have I/O
signature related with the physical parameters, I think it could be
valuable to consider the corresponding benefit and challenges, if the
physical parameters is dynamic while we still want to keep the good thing
from the parameter based I/O signature.

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


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Can the io signatur of the gnuradio blocks be dynamically updated?

[Alex Zhang]

Let me take an example for my question.

For some OFDM blocks, the io signature is determined by the fft length,
during the constructing the block. However, sometimes, we need to adjust
the the fft length dynamically based on some physical environment or
computing environment.

On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang  wrote:

> Hi,
>
> I know it may not be possible in the current gnuradio blocks framework,
> but I am still curious if it can be done.
> When I write a signal processing block, the io signature could be
> determined by some parameters. It is ok, if these parameters are fixed. But
> sometimes, especially in the adaptive system, I need to dynamically update
> these parameter, which result in the updating of io signature of the
> blocks. I can make the io_signature to be independent with the dynamic
> parameters, but it could be more convenient if the io signature can be
> adapted. Of course, it is not easy, as the io signature change could impact
> the upstream and downstream.
>
> Thanks,
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Can the io signatur of the gnuradio blocks be dynamically updated?

[Alex Zhang]

Hi,

I know it may not be possible in the current gnuradio blocks framework, but
I am still curious if it can be done.
When I write a signal processing block, the io signature could be
determined by some parameters. It is ok, if these parameters are fixed. But
sometimes, especially in the adaptive system, I need to dynamically update
these parameter, which result in the updating of io signature of the
blocks. I can make the io_signature to be independent with the dynamic
parameters, but it could be more convenient if the io signature can be
adapted. Of course, it is not easy, as the io signature change could impact
the upstream and downstream.

Thanks,

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tuning in uhd_fft.py

[Alex Zhang]

Found this mail, it seems that the DC removal is still on implementing?  If
so, the tune request can not solve the DC problem at all?
Sorry for these questions, as I am really confused by the code and the
observed phenomenon.


On Fri, Aug 17, 2012 at 12:44 PM, Josh Blum  wrote:

>
>
> On 08/17/2012 05:09 AM, Sanat Gulvadi wrote:
> > Greetings,
> >
> > How are the effects of DC mitigated in GNU radio? For example, if I use
> the
> > uhd_fft.py to just scan the spectrum, I do not see any DC spike at the
> > centre frequency. When I looked at the code, it has :
> >
> > r = self.u.set_center_freq(target_freq, 0)
> >
> > So I assume, it does not use the advanced tuning feature of UHD. Is this
> > correct? How, in this case is there no DC spike seen at the centre
> > frequency?
> > I am trying to code a scanning system that goes through the whole
> frequency
> > band of my RFX2400 dboard and at each center frequency, I grab a packet
> > from the air and apply an FFT to check for possible interferers etc. But
> I
> > am ending up with a spike at every centre frequency iteration. I have
> used
> > the two stage advanced tuning to try and push the DC leakage out of my
> band
> > of interest but I see no difference. I still get that single spike. (I am
> > using the UHD library and not GNU Radio)
> >
>
> There is a DC removal in the USRP, but it needs some time to integrate.
> Perhaps in the gnuradio case, you are looking at an FFT that has had
> some time to integrate at the new frequency. But in your finite
> acquisition case, there is no time.
>
> -josh
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Can not remove the receiving spike (DC component) by advanced tune request at USRP N210.

[Alex Zhang]

Hi,

I always get a strong spike in the attachment, when using uhd_fft to
measure the noise. Please note there is no any signal on the air, only
noise, but I got this spike.
I guess this is the so called DC component. Thus I tried to remove this
spike, as stated in
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes,
using the advanced tuning request.

My sample rate is 2Ms, so as my understanding, I need to set the lo_offset
as >= 4MHz, to get the spike out my band, like this:

tune_req = uhd.tune_request(options.freq, 5e6)   # with lo_offset =
5MHz
usrp.set_center_freq(tune_req, 0)

Then I get the tune result as:

Tune Result:
Target RF  Freq: 2405.00 (MHz)
Actual RF  Freq: 2405.00 (MHz)
Target DSP Freq: 5.00 (MHz)
Actual DSP Freq: 5.00 (MHz)

However, the spike is still there, almost the same, and the center
frequency is even still the same (this could be due to the some GUI usage)!
I really don't know if the advanced tuning works or not. It seems that the
incoming streaming still contains the DC component.

Spike of the received noise.


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

Re: [Discuss-gnuradio] simple ARQ MAC over TDMA; using GNU Radio and USRPs in GRC

[Alex Zhang]

Hi Josh,

A quick question, what is the time reference you are using for the TDMA
engine? Is it GPS or something else? How accurate about the time
synchronization?

On Wed, Sep 26, 2012 at 1:31 PM, Josh Blum  wrote:

> Hey list,
>
> For those who were not at the GR Conference 2012: I presented some work
> demonstrating a simple ARQ MAC over TDMA; using GNU Radio and USRPs in
> GRC. Its very cool work, I encourage anyone to take a peek at the
> slides, and checkout the repo and run the examples.
>
> The MAC layer work is actually the work of John Malsbury (I'm just the
> messenger). He will be continually polishing and debugging the code over
> the next week or so. There should be a wiki page soon...
>
> So, I promised at the presentation that I would email the slides and the
> relevant information to checkout the repository.
>
> 
> -- Here is the presentation (pdf format):
> 
>
> https://github.com/guruofquality/grextras/blob/pre_cog/pre_cog_pres.pdf?raw=true
>
> 
> -- Here are some teaser screenshots from the slides:
> 
> http://i.imgur.com/HYgeb.png
> http://i.imgur.com/EvDof.png
>
> 
> -- The code is available on the pre_cog branch of grextras:
> 
> GRExtras main wiki page:
> https://github.com/guruofquality/grextras/wiki
> GitHub URL
> $ git clone https://github.com/guruofquality/grextras.git
> Check out this branch:
> $ git checkout pre_cog
> GRC flowgraphs are here:
> /examples/*.grc
> Contact
> j...@ettus.com
> j...@ettus.com
>
> *Note*: Users will have to generate the tdma hier block first, and then
> reload GRC to use the top level simple MAC block.
>
> 
> Feedback is always welcome!
> -Josh
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Waiting too much time for the GPS to be synchronized

[Alex Zhang]

Hi,

I have two USRPs with GPS equipped. I found it always took too much for the
two GPS to be sychronized to the same time (diff < 0.1s).
Previously, I wait about 1 or 2 hours, but today 10 hours later, they still
have time difference of 5s.

I am using GPS indoor  environment.

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How can I know which USRP is installed GPS?

[Alex Zhang]

Hi

My PC is connected with 2 USRPs and one of them is connected with GPS and
the other one is using the MIMO cable to share the GPS.
My question is, is it possible to use the Python code to detect which USRP
is equipped with GPS, and which is not?

Thanks，
-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Is there python code to automatically find USRP2 devices

[Alex Zhang]

Just found the swig interface for this feature is already provided...

On Mon, Sep 17, 2012 at 5:32 PM, Alex Zhang  wrote:

> Hi,
>
> Instead of specifying the device address in instantiating the
> usrp_resouce, I would like to let my python code to automatically detect
> the connected USRP and return the device addresses, just like the
> UHD_FIND_DEVICES does. After I get all the addresses of the connected
> USRPs, then the pyhon code can instantiate the instance of USRP_Source.
> I am wondering if there are existing code doing such kind of things. If no
> I will implement by myself.
>
> Best regards,
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Is there python code to automatically find USRP2 devices

[Alex Zhang]

Hi,

Instead of specifying the device address in instantiating the usrp_resouce,
I would like to let my python code to automatically detect the connected
USRP and return the device addresses, just like the UHD_FIND_DEVICES does.
After I get all the addresses of the connected USRPs, then the pyhon code
can instantiate the instance of USRP_Source.
I am wondering if there are existing code doing such kind of things. If no
I will implement by myself.

Best regards,

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] TUN/TAP interface advantage

[Alex Zhang]

Cool.
How can I get this information at that time?

On Sat, Sep 15, 2012 at 11:21 PM, Josh Blum  wrote:

>
>
> On 09/15/2012 11:45 PM, usrp n210 wrote:
> > Is there any advantage to use TUN/TAP interface ?
>
> Tun/tap is a convenient way to get access to the network stack from
> userspace. Unfortunately the benchmark* apps abuse tun/tap as a mac
> layer, which is precisely the wrong thing to do.
>
> For example:
>
> https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_over_wireless_networks
>
> (if you wait a few days, there will be some sweet work released with MAC
> layer + message passing in GRC. Stay tuned...)
>
> -josh
>
> > As 802.11bbn also uses TUN/TAP interface.
> > But I think in the tun/tap performance degrades as we send the packet
> back
> > to user process?
> > Therefore I compare results with benchmark_xx.py in /ofdm  with tunnel.py
> > in /ofdm.
> > In results benchmark_xx.py do not give consistent throughput (i.e. it
> > varies on channel) but tunnel.py gives 100% throughput irrespective of
> > channel
> > Will there be any valid reason for this ?
> > If I want to implement 2-way communication in USRP should I use TUN/TAP
> > interface?
> >
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] python crash or exit when manually start streaming from USRP

[Alex Zhang]

On Wed, Sep 12, 2012 at 12:21 PM, Josh Blum  wrote:

> Just curious. Are you trying to implement a discontinuous streaming
> model? Or are you looking for a way to control start time but still
> continuous?
>
> >
> > case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
> > //Assume that the user called stop() on the flow graph.
> > //However, a timeout can occur under error conditions.
> > if (_start_on_demand == true)
> > //Start is first called by the gr_block_executor
> > //We are still waiting for the mannual start command
> > return work(noutput_items, input_items, output_items);
> >
> > return WORK_DONE;
> >
>
>
> FWIW, the current source block actually has a change to loop forever in
> the work function until the thread interrupted. This is because source
> blocks in gnuradio cannot return from the work function without
> producing. Although, it would be very nice for blocks like uhd source,
> udp source, and probably a few others that block on input IO to be able
> to return from work without producing.
>
> >
> > Unfortunately, although the new code passes the build, the behavior is
> > still strange, for below python code:
> > tb.start()# start flow graph
> > time.sleep(10)  # wait 10 seconds to start the streaming
> > tb.source.u.start()
> >
> > Now the streaming is not started when tb.start() is called in the
> > beginning.  But when 10 seconds sleep ends, the flow graph crashes by
> > reporting: "***glibc detected *** python: corrupted double-linked list:
> > 0x7fcb640011c0", apparently on calling the
> > usrp_source.start() manually. I seems some memory issue happens, but in
> > usrp_source.start(), it just tries send a command to USRP.
> >
> > I suppose the streaming start and stop should be used easily but not know
> > why such kind of problem happens.
> > Still debugging it, any comments are appreciated.
> >
>
> I guess its necessary to determine which line of c++ is actually causing
> the error.
>
> One thing you may check, since you are stopping the first start from
> happening, is the rx streamer still getting created? The rx streamer
> needs to be created before work is called. You may want to check if the
> streamer is created so 1) you can avoid re-allocation, 2) stop work from
> calling into null streamer
>
> Thanks!! Just found the in the usrp_source.start(), the _rx_stream is
allocated every time, causing re-allocation.
I should notice this, as the finite_aqcusition already has the similar code
to avoid the similar problem, :(
Now changed to below code, and the manual start works!

bool start(void){
#ifdef GR_UHD_USE_STREAM_API
//alex, avoid _rx_stream reallocation!!
if (!_rx_stream){
_rx_stream = _dev->get_rx_stream(_stream_args);
_samps_per_packet = _rx_stream->get_max_num_samps();
}
#endif

// alex: need to wait the demand to start the streaming
// Note, start is firstly called by the gr_block_executor
constructor
_start_count++; //update the _start_count to enbale the next start
streaming.
if (_start_on_demand == true && _start_count == 1){
return true; //First time called, not streaming
}

-josh
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] python crash or exit when manually start streaming from USRP

[Alex Zhang]

On Wed, Sep 12, 2012 at 12:21 PM, Josh Blum  wrote:

> Just curious. Are you trying to implement a discontinuous streaming
> model? Or are you looking for a way to control start time but still
> continuous?
>
I think I want a way to control start time but still continuous. But I may
know not so much about discontinuous  streaming. What is the difference
between the discontinuous streaming and the finite acquisition?

>
> >
> > case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
> > //Assume that the user called stop() on the flow graph.
> > //However, a timeout can occur under error conditions.
> > if (_start_on_demand == true)
> > //Start is first called by the gr_block_executor
> > //We are still waiting for the mannual start command
> > return work(noutput_items, input_items, output_items);
> >
> > return WORK_DONE;
> >
>
>
> FWIW, the current source block actually has a change to loop forever in
> the work function until the thread interrupted. This is because source
> blocks in gnuradio cannot return from the work function without
> producing. Although, it would be very nice for blocks like uhd source,
> udp source, and probably a few others that block on input IO to be able
> to return from work without producing.
>
> >
> > Unfortunately, although the new code passes the build, the behavior is
> > still strange, for below python code:
> > tb.start()# start flow graph
> > time.sleep(10)  # wait 10 seconds to start the streaming
> > tb.source.u.start()
> >
> > Now the streaming is not started when tb.start() is called in the
> > beginning.  But when 10 seconds sleep ends, the flow graph crashes by
> > reporting: "***glibc detected *** python: corrupted double-linked list:
> > 0x7fcb640011c0", apparently on calling the
> > usrp_source.start() manually. I seems some memory issue happens, but in
> > usrp_source.start(), it just tries send a command to USRP.
> >
> > I suppose the streaming start and stop should be used easily but not know
> > why such kind of problem happens.
> > Still debugging it, any comments are appreciated.
> >
>
> I guess its necessary to determine which line of c++ is actually causing
> the error.
>
> One thing you may check, since you are stopping the first start from
> happening, is the rx streamer still getting created? The rx streamer
> needs to be created before work is called. You may want to check if the
> streamer is created so 1) you can avoid re-allocation, 2) stop work from
> calling into null streamer
>

Thanks for this indication, I will check if the incorrect object operation.

>
> -josh
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] python crash or exit when manually start streaming from USRP

[Alex Zhang]

Hi all and Josh,

What I want to do is to control the streaming from the USRP by my own
python code.
usrp_source provides the start() and the stop() to control the streaming by
issuing the command to USRP.
However, when I try to use them in my python code, lots of problems block
me.

As my observation, when the flow graph is started, the gr_block.start() is
actually called automatically. And the streaming is started right after the
tb.start(). I want the streaming to be held until I explicitly call the
usrp_source.start(). So I firstly tried usrp_source.stop() firstly as below:

tb.start()# start flow graph
self.source.u.stop()
time.sleep(10)  # wait 10 seconds to start the streaming
tb.source.u.start()

But the flow graph exits instantly at the stop(), as the usrp_source.work()
will return WORK_DONE due to the streaming timeout (see
gr_uhd_usrp_source.cc).

Thus, I decide to change the code in gr_uhd_usrp_source.cc as below:

   1. When the usrp_source.start() is firstly called by the
constructor of gr_block_executor,
   I hold the streaming command. So the streaming will not be started when
   tb.start().
   2. When usrp_source.start() is called in the second times, the streaming
   command is really issued to USRP. Code is like this:

bool start(void){
#ifdef GR_UHD_USE_STREAM_API
_rx_stream = _dev->get_rx_stream(_stream_args);
_samps_per_packet = _rx_stream->get_max_num_samps();
#endif

// alex: need to wait the demand to start the streaming
// Note, start is firstly called by the gr_block_executor
constructor
_start_count++; //update the _start_count to enbale the next start
streaming.
if (_start_on_demand == true && _start_count == 1){
return true; //First time called, not streaming
}

   1. In  gr_uhd_usrp_source::work(), if ERROR_CODE_TIMEOUT is reported,
   the code will try more instead of returning WORK_DONE:

case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
//Assume that the user called stop() on the flow graph.
//However, a timeout can occur under error conditions.
if (_start_on_demand == true)
//Start is first called by the gr_block_executor
//We are still waiting for the mannual start command
return work(noutput_items, input_items, output_items);

return WORK_DONE;


Unfortunately, although the new code passes the build, the behavior is
still strange, for below python code:
tb.start()# start flow graph
time.sleep(10)  # wait 10 seconds to start the streaming
tb.source.u.start()

Now the streaming is not started when tb.start() is called in the
beginning.  But when 10 seconds sleep ends, the flow graph crashes by
reporting: "***glibc detected *** python: corrupted double-linked list:
0x7fcb640011c0", apparently on calling the
usrp_source.start() manually. I seems some memory issue happens, but in
usrp_source.start(), it just tries send a command to USRP.

I suppose the streaming start and stop should be used easily but not know
why such kind of problem happens.
Still debugging it, any comments are appreciated.

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] What is the minimum sample rate of the USRP

[Alex Zhang]

Hi,

When I want to set the sample rate as very low as 20k, but the running
result show me that it is increased to about 195k automatically as 20k
sample rate is not supported.

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Is it possible to read the ADC samples before the downconversion from the USRP?

[Alex Zhang]

Exactly what I want, thanks!

On Wed, Aug 15, 2012 at 2:48 PM, Josh Blum  wrote:

> Marc Epard had a project to burst 100 Msps samples into the SRAM.
> https://lists.gnu.org/archive/html/discuss-gnuradio/2011-03/msg00300.html
>
> On 08/15/2012 12:24 PM, Alex Zhang wrote:
> > In short, I want to get the samples right after the ADC, without any
> > down-conversion, decimation, and filter, etc.
> >
> > On Wed, Aug 15, 2012 at 11:52 AM, Nick Foster  wrote:
> >
> >> There is generally no IF on a USRP: it's all baseband, even at the ADC.
> >> That said, you need decimation in order to fit the full-speed baseband
> data
> >> over the 1Gbit (or USB) link. There is an existing user FPGA
> modification
> >> somewhere that buffers full-speed baseband data into the SRAM on an N210
> >> for later retrieval. What exactly are you trying to do?
> >>
> >> --n
> >>
> >> On Wed, Aug 15, 2012 at 9:38 AM, Alex Zhang  >wrote:
> >>
> >>> Hi,
> >>>
> >>> I want to collect the samples of the USRP at the IF instead of the
> >>> baseband, so is there any way to read the ADC samples directly without
> >>> downconversion, at the PC?
> >>> I do not want to touch the FPGA.
> >>>
> >>> --
> >>>
> >>> Alex,
> >>> *Dreams can come true – just believe.*
> >>>
> >>>
> >>> ___
> >>> USRP-users mailing list
> >>> usrp-us...@lists.ettus.com
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >>>
> >>
> >
> >
> >
> >
> > ___
> > USRP-users mailing list
> > usrp-us...@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Is it possible to read the ADC samples before the downconversion from the USRP?

[Alex Zhang]

In short, I want to get the samples right after the ADC, without any
down-conversion, decimation, and filter, etc.

On Wed, Aug 15, 2012 at 11:52 AM, Nick Foster  wrote:

> There is generally no IF on a USRP: it's all baseband, even at the ADC.
> That said, you need decimation in order to fit the full-speed baseband data
> over the 1Gbit (or USB) link. There is an existing user FPGA modification
> somewhere that buffers full-speed baseband data into the SRAM on an N210
> for later retrieval. What exactly are you trying to do?
>
> --n
>
> On Wed, Aug 15, 2012 at 9:38 AM, Alex Zhang wrote:
>
>> Hi,
>>
>> I want to collect the samples of the USRP at the IF instead of the
>> baseband, so is there any way to read the ADC samples directly without
>> downconversion, at the PC?
>> I do not want to touch the FPGA.
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Is it possible to read the ADC samples before the downconversion from the USRP?

[Alex Zhang]

Hi,

I want to collect the samples of the USRP at the IF instead of the
baseband, so is there any way to read the ADC samples directly without
downconversion, at the PC?
I do not want to touch the FPGA.

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210

[Alex Zhang]

Could I know your current achieved bandwidth of OFDM communication over
GNURadio on your platform?

On Tue, Aug 7, 2012 at 9:55 AM,  wrote:

> **
>
> On 07 Aug 2012 10:49, Nathan West wrote:
>
>
>  Agreed, which is why there is general advice, like enabling real-time
> scheduling for non-root users:
> http://lists.gnu.org/archive/html/discuss-gnuradio/2010-07/msg00463.html
>
> You should also run volk_profile :
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk
>
> And if you think the link between the USRP and your PC is an issue you
> shouldn't use any kind of hub/switch.
>
> -Nathan
>
> I've found that if you're consistently running out of steam, enabling
> real-time scheduling doesn't help.
>
>
>
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210

[Alex Zhang]

On Tue, Aug 7, 2012 at 9:12 AM,  wrote:

> **
>
> On 06 Aug 2012 17:59, Alex Zhang wrote:
>
> Just state, I was using the tunnel.py instead of the rawOFDM to do the
> test. Seems nobody declared good bitrate within this community, although I
> have asked for many times.
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
> Nobody has answered because there is no single answer.  Your achievable
> performance depends on too many factors for anyone to come up with a
> reasonable answer.
>
Yes, I agree with you that there are many factors to impact the
performance. So I keep asking what is the best performance has been
achieved within the community, and then I can compare with them to find out
the possible space to improve the bandwidth supported. What I just need is
just an concrete number for benchmark. If any guy claims the good result, I
will know I still can do something to beat the limit.

> Different computers, with very different performance levels, different OS
> distributions with different optimizations in different parts of the
> kernel.  And that's ignoring any of the path distortions that may be
> present between your radios.
>
> The fact is that general-purpose operating systems aren't well-optimized
> for real-time, high-bandwidth, digital signal processing, even on systems
> where the "raw" compute power would seem to be adequate. The path lengths
> (in terms of number of executed instructions) between data sources and the
> calculations are much longer than they would be in a compute environment
> optimized for the job.
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210

[Alex Zhang]

I use the Benchmark OFDM instead fo RawOFDM, but I think the basic
synchronization algorithm is the same.
UT austin has a project Hydra which is using the OFDM modulation,
http://netlab.ece.utexas.edu/hydra/
but I did not see any record about the bitrate they achieved. Someone else
told me that Hydra does not have big bandwidth.

24MHz is impossible to be achieved, as the maximum USRP sample rate is
25M/S for 16bit sample, except you use your own frond end.

8 Core at 3.3G PC should have improvement on the supported bandwidth. But I
don't know what performance it can achieve. Currently I am using the 4Core
as yours.

The GNURadio has its own automatic parallelism like VOLK to support SIMD
acceleration. So I dont think you need additional work to support
multi-core computing. But you may consider using the GPU.

Here the paper has some literature review on the USRP usage.
http://iweb.tntech.edu/rqiu/publications/JCMQiu_2012.pdf

On Mon, Aug 6, 2012 at 9:33 PM, Qing Yang  wrote:

> Hi Alex,
>
> Thanks for sharing your experience. Are you using RawOFDM or Benchmark
> OFDM?
>
> I agree with you that we need more powerful PCs because for large
> bandwidth we have too much samples to process. Furthermore, the bottleneck
> is definitely in the receiving part because in our system the transmitter
> can support 20MHz OFDM transmitting well. And the signal processing
> complexity of OFDM receiver is much higher than transmitter.
>
> I think our PCs are powerful enough (4 cores cpu at 2.4G) and we are ready
> to purchase some more powerful PCs (8 cores at 3.3G). But I wonder that
> even 3.3G cpu still cannot support 20MHz bandwidth.
>
> Does anyone have other solutions such as using parallel signal processing
> or multi-thread? We have 8-core cpu but we don't know how to fully utilize
> them using gr.
>
> Sincerely,
> --
> Yang, Qing
> Information Engineering, CUHK
>
>
>
> 2012/8/7 Alex Zhang 
>
>> Just state, I was using the tunnel.py instead of the rawOFDM to do the
>> test. Seems nobody declared good bitrate within this community, although I
>> have asked for many times.
>>
>>
>> On Mon, Aug 6, 2012 at 3:06 PM, Alex Zhang wrote:
>>
>>> Hi Qing,
>>>
>>> Your experience is exactly what I have tested. The data rate of OFDM
>>> based on the current GNURadio never exceeds 1Mbps with acceptable PER.
>>> I guess the only way to beat more bandwidth is to use very strong
>>> computer...
>>>
>>> On Mon, Aug 6, 2012 at 10:12 AM, Qing Yang wrote:
>>>
>>>> Dear all,
>>>>
>>>> Recently we are building an OFDM communication system based on RawOFDM(
>>>> http://people.csail.mit.edu/szym/rawofdm/README.html). In the simplest 
>>>> point-to-point
>>>> case, we use a pair of PC and USRP as the transmitter and use another pair
>>>> as the receiver.
>>>>
>>>> To reduce the influence of CFO, we need to run our system with large
>>>> bandwidth (like 802.11 at 20MHz). However, once we set the
>>>> transmitting bandwidth larger than 2MHz, the receiver's program will block
>>>> there and show "over-run" message later on (a screen of "O"s). For small
>>>> bandwidth (<2MHz), the receiver runs pretty well.
>>>>
>>>> Do you have similar experience? How can I make the OFDM receiver work
>>>> with 20MHz bandwidth?
>>>>
>>>>
>>>>
>>>> We use USRP N210. And the configuration of our PC is
>>>> Ubuntu release 10.10(maverick) kernel 2.6.35-22-generic GNOME 2.32.0
>>>> Memory: 15.7GiB
>>>> Processor 0~7: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
>>>>
>>>> UHD version: UHD_003.004.000-c50bb91 image version 8
>>>> gnuradio version: 3.4.x
>>>>
>>>>
>>>> Sincerely,
>>>> --
>>>> Yang, Qing
>>>> Information Engineering, CUHK
>>>>
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Alex,
>>> *Dreams can come true – just believe.*
>>>
>>>
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210

[Alex Zhang]

Just state, I was using the tunnel.py instead of the rawOFDM to do the
test. Seems nobody declared good bitrate within this community, although I
have asked for many times.

On Mon, Aug 6, 2012 at 3:06 PM, Alex Zhang  wrote:

> Hi Qing,
>
> Your experience is exactly what I have tested. The data rate of OFDM based
> on the current GNURadio never exceeds 1Mbps with acceptable PER.
> I guess the only way to beat more bandwidth is to use very strong
> computer...
>
> On Mon, Aug 6, 2012 at 10:12 AM, Qing Yang  wrote:
>
>> Dear all,
>>
>> Recently we are building an OFDM communication system based on RawOFDM(
>> http://people.csail.mit.edu/szym/rawofdm/README.html). In the simplest 
>> point-to-point
>> case, we use a pair of PC and USRP as the transmitter and use another pair
>> as the receiver.
>>
>> To reduce the influence of CFO, we need to run our system with large
>> bandwidth (like 802.11 at 20MHz). However, once we set the transmitting
>> bandwidth larger than 2MHz, the receiver's program will block there and
>> show "over-run" message later on (a screen of "O"s). For small bandwidth
>> (<2MHz), the receiver runs pretty well.
>>
>> Do you have similar experience? How can I make the OFDM receiver work
>> with 20MHz bandwidth?
>>
>>
>>
>> We use USRP N210. And the configuration of our PC is
>> Ubuntu release 10.10(maverick) kernel 2.6.35-22-generic GNOME 2.32.0
>> Memory: 15.7GiB
>> Processor 0~7: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
>>
>> UHD version: UHD_003.004.000-c50bb91 image version 8
>> gnuradio version: 3.4.x
>>
>>
>> Sincerely,
>> --
>> Yang, Qing
>> Information Engineering, CUHK
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210

[Alex Zhang]

Hi Qing,

Your experience is exactly what I have tested. The data rate of OFDM based
on the current GNURadio never exceeds 1Mbps with acceptable PER.
I guess the only way to beat more bandwidth is to use very strong
computer...

On Mon, Aug 6, 2012 at 10:12 AM, Qing Yang  wrote:

> Dear all,
>
> Recently we are building an OFDM communication system based on RawOFDM(
> http://people.csail.mit.edu/szym/rawofdm/README.html). In the simplest 
> point-to-point
> case, we use a pair of PC and USRP as the transmitter and use another pair
> as the receiver.
>
> To reduce the influence of CFO, we need to run our system with large
> bandwidth (like 802.11 at 20MHz). However, once we set the transmitting
> bandwidth larger than 2MHz, the receiver's program will block there and
> show "over-run" message later on (a screen of "O"s). For small bandwidth
> (<2MHz), the receiver runs pretty well.
>
> Do you have similar experience? How can I make the OFDM receiver work with
> 20MHz bandwidth?
>
>
>
> We use USRP N210. And the configuration of our PC is
> Ubuntu release 10.10(maverick) kernel 2.6.35-22-generic GNOME 2.32.0
> Memory: 15.7GiB
> Processor 0~7: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
>
> UHD version: UHD_003.004.000-c50bb91 image version 8
> gnuradio version: 3.4.x
>
>
> Sincerely,
> --
> Yang, Qing
> Information Engineering, CUHK
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fwd: Any friends ever worked on noise variance estimation using the USRP?

[Alex Zhang]

Copy to usrp-users

-- Forwarded message --
From: Alex Zhang 
Date: Tue, Jul 24, 2012 at 4:08 PM
Subject: Any friends ever worked on noise variance estimation using the
USRP?
To: gnuradio mailing list 


Hi gurus,

I am doing an experiment which need to estimate the noise variance of each
USRP as receiver.
My question is that besides the sample variance method, is there any other
method to achieve better accuracy?
And for a single USRP, is the variance stable after the power on? And is
the measurement related to working frequency?

-- 

Alex,
*Dreams can come true – just believe.*




-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Any friends ever worked on noise variance estimation using the USRP?

[Alex Zhang]

Hi gurus,

I am doing an experiment which need to estimate the noise variance of each
USRP as receiver.
My question is that besides the sample variance method, is there any other
method to achieve better accuracy?
And for a single USRP, is the variance stable after the power on? And is
the measurement related to working frequency?

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] carrier_sensed() doesn't work in tunnel.py with USRP N210 and XCVR2450

[Alex Zhang]

Apparently you did not set the threshold correctly. Measure the
transmitting power in dB firstly and then adjust the threshold.
btw, are you doing the routing experiment with only two USRPs?

On Thu, Jul 19, 2012 at 4:24 PM, Weixian Zhou  wrote:

> I am doing routing experiment with two USRPs and tunnel.py. Machine A
> keeps sending, and another machine B forwards the message when it receives
> from A. Before B forwards message, it calls tb.carrier_sensed() to do
> exponential back-off. But I have never see the carrier_sensed() works. If
> it works, it should print 'B' and doesn't send when machine A is sending.
> In reality, machine B lost a lot of messages from A, which are supposed to
> be received with carrier_sensed().
>
> --
> Regards,
> Weixian Zhou
>
>
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] about the tunnel.py

[Alex Zhang]

The tunnel.py problem seems being complained for thousand times :)  No
one has final solution now, at least in the archive.

In my experience, actually, this is a full-duplex problem. If your daughter
board can only support half-duplex, you need additional time to switch to
RX right after your transmission.
However, if you use a board of full-duplex, the RX and TX frequency should
have difference more than the bandwidth of the RF (about 40MHz for SBX).
But even I set the |RX - TX| > 40MHz, the flow control at each side is
needed, i.e, the messages can not be transmitted with too short interval,
otherwise, it can not receive the reply in time It is very strange.

On Fri, Jul 13, 2012 at 12:07 AM, CHAO DONG  wrote:

> Josh, thanks.
> Now, when i ping B from A, A can receive some ARP requests but ok=false,
> so A Will not send ARP reply. With the same setting, i use the benchmark, A
> can receive almost all the packets from B and ok=true.
> I think there must be some difference between benchmark and tunnel.
> Who can explain this,？
> 在 2012-7-12 下午4:57，"Josh Blum" 写道：
>
>
>>
>> On 07/11/2012 08:57 PM, CHAO DONG wrote:
>> > Dear all,
>> >
>> >I am testing tunnel.py in the narrowband folder, the
>> > configuration is as follows:
>> > OS: ubuntu 11.10
>> > Gnuradio: latest
>> > UHD:latest
>> > USRP 1
>> > RFX400
>> >
>> > I set up two machines and do following the readme step by step.
>> > When i ping machine B from A, A shows it has sent the ARP request, but
>> > no ARP reply received.
>> > In fact, B did not receive the ARP request at all.
>> >
>> >I use benchmark_rx and benchmark_tx to test the channel, it is ok.
>> >
>> >And when i use: sudo ifconfig gr0 192.168.200.1 on A, B can receive
>> > the IGMP packet from the gr0 of A. This show the gr0 on A and B is ok
>> > for IGMP protocol.
>> >
>> > Welcome any comments!
>> >
>>
>> I recall a similar discussion, and one simple solution was to use a
>> different frequency for each communication channel.
>>
>> So for communication between A -> B use frequencyX
>> and for communication B -> A use frequencyY.
>>
>> I hope that helps!
>> -josh
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tunnel.py destination host unreachable - Temporarily solution, due to too fast reply!

[Alex Zhang]

Jason,

Thanks for information.
If I am not wrong,  I think your problem is from the CSMA threshold. In the
single link case of my mail, A and B shoule always send packet at different
time.

In addition, I am using SBX board. The duplex detail is still devil for me.
:<

On Mon, Jun 18, 2012 at 11:17 PM, Jason Tran  wrote:

> I had a similar problem way back and found collided packets (corrupted
> packets with ok=False). I started digging and found that my
> gr_probe_mag_sqrd_X was not returning a high enough magnitude for the
> carrier sense to be tripped. This also had to do with an issue I was having
> getting the xcvr2450 to tune to the right tx/rx frequencies...
>
> I suggest printing out the result of the magnitude squared to see if this
> is the case as well for you guys.
>
> Regards,
> Jason T.
>
>   ------
> *From:* Alex Zhang 
> *To:* j...@ettus.com
> *Cc:* Tom Rondeau ; gnuradio mailing list <
> discuss-gnuradio@gnu.org>
> *Sent:* Monday, June 18, 2012 9:07 PM
> *Subject:* [Discuss-gnuradio] tunnel.py destination host unreachable -
> Temporarily solution, due to too fast reply!
>
> Hello Josh,
>
> I have seen many guys complaining the tunnel.py failed in PING by the
> "destination host unreachable", for both the OFDM and Narrowband.
> This problem is caused by crushed ARP reply. I previously use the static
> ARP table to work round this problem, but today I did some investigating
> and test, and now I believe the too fast ARP reply from the destination
> causes that the transmitter can not receive this reply or receive it with
> corrupted packets.
>
> For example, if the usrp A send the ARP request at time T, then usrp B
> send back the ARP reply at time T+delta. If the delta is too small, then A
> will definitely fails to receive it.
>
> The  temp solution is as below (tunnel.py in csma_mac.main_loop), just add
> a small delay for B  to send back the ARP reply. This solution works well.
>
>  ... ...**
>
> @@ -185,7 +185,10 @@ def main_loop(self):
>
> 185 185**
>
>  if not payload:
>
> 186 186**
>
>  self.tb.send_pkt(eof=True)
>
> 187 187**
>
>  break
>
> 188  **
>
> -
>
>   188**
>
> +
>
>   189**
>
> +time.sleep(0.009) # delay 9ms before sending out the reply
>
>   190**
>
> +t2 = self.tb.source.u.get_time_now().get_real_secs()
>
>   191**
>
> +print 'reply at time ', t
>
> 189 192**
>
>  if self.verbose:
>
> 190 193**
>
>  print "Tx: len(payload) = %4d" % (len(payload),)
>
>
> The root cause for this problem, I guess, should be that the duplex
> switching time bwteen the TX and RX at USRP is not small enough. More
> details should be about the duplex mechanism of the SBX daughter board. I
> hope there are some other way to solve this problem. For example, I tried
> to specify the TX and RX at different antennas (TX/RX for transmitter, RX2
> for receiver) of the SBX, but unfortunately it seems impossible.
>
> Looking forward to your further comments.
>
> Thanks,
>
> Alex(Changchun) Zhang
> Cognitive Radio Institute @ Tennessee Tech Univ.
>
> -- Forwarded message --
> From: *Alex Zhang* 
> Date: Mon, Jun 18, 2012 at 4:53 PM
> Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
> To: Weixian Zhou 
> Cc: j...@ettus.com, gnuradio mailing list 
>
>
> Weixian,
>
> Here is a temp solution, not sure it works or not:
>
> In the csma_mac.main_loop() of your tunnel.py, add a
> time_sleep(fixed_delay) right after the payload is read from the OS. You
> can set fixed_delay as 0.01 to 0.1 and test the result.
>
> And also, please set the CSMA threshold carefully to avoid
> possible collision.
>
> Alex
>
> On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou  wrote:
>
> The following is the messages of the transmitter after I ping. The
> packages of len(payload)=42 failed CRC check, but other packages succeed.
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   90*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  220*
> *UTx: len(payload) =  326*
> *URx: ok = False  len(payload) =  326*
> *Tx: len(payload) =   81*
>  *UTx: len(payload) =  326*
> *UTx: len(payload) =  326*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   78*
> *UTx: len(payload) =  220*
> *URx: ok = False  len(payload) =  220*
> *Tx: len(payload) =   81*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   70*
> *UTx: len(paylo

[Discuss-gnuradio] tunnel.py destination host unreachable - Temporarily solution, due to too fast reply!

[Alex Zhang]

Hello Josh,

I have seen many guys complaining the tunnel.py failed in PING by the
"destination host unreachable", for both the OFDM and Narrowband.
This problem is caused by crushed ARP reply. I previously use the static
ARP table to work round this problem, but today I did some investigating
and test, and now I believe the too fast ARP reply from the destination
causes that the transmitter can not receive this reply or receive it with
corrupted packets.

For example, if the usrp A send the ARP request at time T, then usrp B send
back the ARP reply at time T+delta. If the delta is too small, then A will
definitely fails to receive it.

The  temp solution is as below (tunnel.py in csma_mac.main_loop), just add
a small delay for B  to send back the ARP reply. This solution works well.

..**

@@ -185,7 +185,10 @@ def main_loop(self):

185185**

 if not payload:

186186**

 self.tb.send_pkt(eof=True)

187187**

 break

188 **

-

 188**

+

 189**

+time.sleep(0.009) # delay 9ms before sending out the reply

 190**

+t2 = self.tb.source.u.get_time_now().get_real_secs()

 191**

+print 'reply at time ', t

189192**

 if self.verbose:

190193**

 print "Tx: len(payload) = %4d" % (len(payload),)


The root cause for this problem, I guess, should be that the duplex
switching time bwteen the TX and RX at USRP is not small enough. More
details should be about the duplex mechanism of the SBX daughter board. I
hope there are some other way to solve this problem. For example, I tried
to specify the TX and RX at different antennas (TX/RX for transmitter, RX2
for receiver) of the SBX, but unfortunately it seems impossible.

Looking forward to your further comments.

Thanks,

Alex(Changchun) Zhang
Cognitive Radio Institute @ Tennessee Tech Univ.

-- Forwarded message --
From: Alex Zhang 
Date: Mon, Jun 18, 2012 at 4:53 PM
Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
To: Weixian Zhou 
Cc: j...@ettus.com, gnuradio mailing list 


Weixian,

Here is a temp solution, not sure it works or not:

In the csma_mac.main_loop() of your tunnel.py, add a
time_sleep(fixed_delay) right after the payload is read from the OS. You
can set fixed_delay as 0.01 to 0.1 and test the result.

And also, please set the CSMA threshold carefully to avoid
possible collision.

Alex

On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou  wrote:

> The following is the messages of the transmitter after I ping. The
> packages of len(payload)=42 failed CRC check, but other packages succeed.
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   90*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  220*
> *UTx: len(payload) =  326*
> *URx: ok = False  len(payload) =  326*
> *Tx: len(payload) =   81*
>  *UTx: len(payload) =  326*
> *UTx: len(payload) =  326*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   78*
> *UTx: len(payload) =  220*
> *URx: ok = False  len(payload) =  220*
> *Tx: len(payload) =   81*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   70*
> *UTx: len(payload) =  110*
> *UTx: len(payload) =  240*
> *URx: ok = False  len(payload) =  240*
> *Tx: len(payload) =  404*
>  *Tx: len(payload) =  201*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =  114*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =  240*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  318*
> *UTx: len(payload) =   81*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *URx: ok = False  len(payload) =  189*
> *Tx: len(payload) =  302*
> *UTx: len(payload) =   90*
> *UTx: len(payload) =  350*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =   70*
>  *UTx: len(payload) =   81*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =   70*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = True  len(payload) =   81*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   81*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =  101*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) = 

Re: [Discuss-gnuradio] tunnel.py destination host unreachable

[Alex Zhang]

Weixian,

Here is a temp solution, not sure it works or not:

In the csma_mac.main_loop() of your tunnel.py, add a
time_sleep(fixed_delay) right after the payload is read from the OS. You
can set fixed_delay as 0.01 to 0.1 and test the result.

And also, please set the CSMA threshold carefully to avoid
possible collision.

Alex

On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou  wrote:

> The following is the messages of the transmitter after I ping. The
> packages of len(payload)=42 failed CRC check, but other packages succeed.
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   90*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  220*
> *UTx: len(payload) =  326*
> *URx: ok = False  len(payload) =  326*
> *Tx: len(payload) =   81*
>  *UTx: len(payload) =  326*
> *UTx: len(payload) =  326*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   78*
> *UTx: len(payload) =  220*
> *URx: ok = False  len(payload) =  220*
> *Tx: len(payload) =   81*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   70*
> *UTx: len(payload) =  110*
> *UTx: len(payload) =  240*
> *URx: ok = False  len(payload) =  240*
> *Tx: len(payload) =  404*
>  *Tx: len(payload) =  201*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =  114*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =  240*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  318*
> *UTx: len(payload) =   81*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *URx: ok = False  len(payload) =  189*
> *Tx: len(payload) =  302*
> *UTx: len(payload) =   90*
> *UTx: len(payload) =  350*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =   70*
>  *UTx: len(payload) =   81*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =   70*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = True  len(payload) =   81*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   81*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =  101*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
>  *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   81*
> *UTx: len(payload) =  101*
> *URx: ok = True  len(payload) =   81*
> *Rx: ok = True  len(payload) =  101*
>
>
> On Mon, Jun 18, 2012 at 11:01 AM, Weixian Zhou  wrote:
>
>> Hi Alex,
>> After tried many times I found that the transmitter actually received
>> packages of len(payload)=42 from the receiver, but the the packages failed
>> CRC check (ok=false). I think some parameters need to be tuned, maybe
>> bitrate?
>>
>> On Mon, Jun 18, 2012 at 10:21 AM, Weixian Zhou  wrote:
>>
>>> Hi Alex,
>>> I tried it. The problem is the same. The transmitter only showed tx
>>> message of len(payload) = 42, and the receiver showed both tx/rx messages
>>> of len(payload) = 42.
>>>
>>>
>>> On Fri, Jun 15, 2012 at 6:43 PM, Alex Zhang wrote:
>>>
>>>> Weixian,
>>>>
>>>> Could you please try the ping command like this (if you are working on
>>>> linux):
>>>>
>>>> *sudo ping 192.168.200.2 -i 0.01*
>>>>
>>>> -i 0.01 means the time interval between pings is 0.01 second. And tell
>>>> me what happened.
>>>> You can try different time intervals.
>>>>
>>>>
>>>> On Fri, Jun 15, 2012 at 5:37 PM, Alex Zhang wrote:
>>>>
>>>>> I did the tes

Re: [Discuss-gnuradio] tunnel.py destination host unreachable

[Alex Zhang]

Weixian,

Could you please try the ping command like this (if you are working on
linux):

*sudo ping 192.168.200.2 -i 0.01*

-i 0.01 means the time interval between pings is 0.01 second. And tell me
what happened.
You can try different time intervals.

On Fri, Jun 15, 2012 at 5:37 PM, Alex Zhang  wrote:

> I did the test by myself, and the most of the time ARP queries failed
> I met this problem when I do the OFDM link test, but that is because the
> physical layer is not robust. But for this narrow band (GMSK) modulation, I
> am not sure what the problem is.
>
> May Josh knows... :)
>
>
> On Fri, Jun 15, 2012 at 3:05 PM, Alex Zhang wrote:
>
>> Something like discarded.
>>
>>
>> On Fri, Jun 15, 2012 at 11:59 AM, Weixian Zhou  wrote:
>>
>>> What do you mean by "it may be consumed"?
>>>
>>>
>>> On Fri, Jun 15, 2012 at 12:44 PM, Alex Zhang wrote:
>>>
>>>> Did you see RX False at the receiver for the ARP reply? If that is not
>>>> seen, it could be due to some reason causing the ARP reply is not sent out
>>>> at all. Although you see the log for the TX packet in the CSMA mainloop,
>>>> but it may be consumed before or when  it goes to the transmitting path...
>>>>
>>>> On Fri, Jun 15, 2012 at 10:49 AM, Weixian Zhou wrote:
>>>>
>>>>> Yes, the ARP is replied. But another machine did not received and
>>>>> showed "Destination Host Unreachable".
>>>>>
>>>>> On Fri, Jun 15, 2012 at 11:19 AM, Alex Zhang 
>>>>> wrote:
>>>>>
>>>>>> Do you check the ARP reply is sent out or not?
>>>>>> I am not sure if there are some flow control issues for the
>>>>>> networking.
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 15, 2012 at 10:02 AM, Weixian Zhou wrote:
>>>>>>
>>>>>>> Thanks for responses. The problem that confused me is that when I
>>>>>>> on machine A:
>>>>>>> *sudo ./tunnel.py --tx-freq=2.51G --rx-freq=2.515G -c 50 -r 0.5M *
>>>>>>> then
>>>>>>> *sudo ifconfig gr0 192.168.200.1*
>>>>>>>
>>>>>>> on machine B:
>>>>>>> *sudo ./tunnel.py --tx-freq=2.515G --rx-freq=2.51G -c 50 -r 0.5M *
>>>>>>> then
>>>>>>> *sudo ifconfig gr0 192.168.200.2*
>>>>>>>
>>>>>>> I can see packages tx/rx succeed on both machines. But the ping
>>>>>>> failed and one machine did not rx. Why is that?
>>>>>>>
>>>>>>> On Thu, Jun 14, 2012 at 4:38 PM, Alex Zhang >>>>>> > wrote:
>>>>>>>
>>>>>>>> Most likely you did not set the freq and gain properly.  Unstable
>>>>>>>> physical layer communications cause the ARP routing failure.
>>>>>>>> Please use different frequencies for tx and rx.
>>>>>>>>
>>>>>>>> On Thu, Jun 14, 2012 at 1:51 PM, Weixian Zhou wrote:
>>>>>>>>
>>>>>>>>> I was testing with tunnel.py and following the instructions in
>>>>>>>>> README located in gnuradio/gr-digital/examples/narrwoband.
>>>>>>>>> I found that when I input* ifconfig gr0 192.168.200.1* on machine
>>>>>>>>> A, and input* ifconfig gr0 192.168.200.2* on machine B at the
>>>>>>>>> same time, both machines showed Tx and Rx packages.
>>>>>>>>> But when I* ping 192.168.200.2* from machine A ( or *ping
>>>>>>>>> 192.168.200.1* from machine B respectively), one window of
>>>>>>>>> machine A only showed Tx packages and another window showed 
>>>>>>>>> "Destination
>>>>>>>>> Host Unreachable". Machine B showed both Rx/Tx packages.
>>>>>>>>> It means that machine B can successfully received packages from
>>>>>>>>> machine A but A failed to receive replied packages from machine B. It
>>>>>>>>> confused me that the packages tx/rx were succeed before the ping. 
>>>>>>>>> Anyone
>>>>>>>>> has idea?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards,
>>>>>>>>> Weixian Zhou
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>>> Discuss-gnuradio@gnu.org
>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Alex,
>>>>>>>> *Dreams can come true – just believe.*
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Weixian Zhou
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Alex,
>>>>>> *Dreams can come true – just believe.*
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Weixian Zhou
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Alex,
>>>> *Dreams can come true – just believe.*
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Weixian Zhou
>>>
>>>
>>>
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tunnel.py destination host unreachable

[Alex Zhang]

I did the test by myself, and the most of the time ARP queries failed I
met this problem when I do the OFDM link test, but that is because the
physical layer is not robust. But for this narrow band (GMSK) modulation, I
am not sure what the problem is.

May Josh knows... :)

On Fri, Jun 15, 2012 at 3:05 PM, Alex Zhang  wrote:

> Something like discarded.
>
>
> On Fri, Jun 15, 2012 at 11:59 AM, Weixian Zhou  wrote:
>
>> What do you mean by "it may be consumed"?
>>
>>
>> On Fri, Jun 15, 2012 at 12:44 PM, Alex Zhang wrote:
>>
>>> Did you see RX False at the receiver for the ARP reply? If that is not
>>> seen, it could be due to some reason causing the ARP reply is not sent out
>>> at all. Although you see the log for the TX packet in the CSMA mainloop,
>>> but it may be consumed before or when  it goes to the transmitting path...
>>>
>>> On Fri, Jun 15, 2012 at 10:49 AM, Weixian Zhou wrote:
>>>
>>>> Yes, the ARP is replied. But another machine did not received and
>>>> showed "Destination Host Unreachable".
>>>>
>>>> On Fri, Jun 15, 2012 at 11:19 AM, Alex Zhang 
>>>> wrote:
>>>>
>>>>> Do you check the ARP reply is sent out or not?
>>>>> I am not sure if there are some flow control issues for the
>>>>> networking.
>>>>>
>>>>>
>>>>> On Fri, Jun 15, 2012 at 10:02 AM, Weixian Zhou wrote:
>>>>>
>>>>>> Thanks for responses. The problem that confused me is that when I
>>>>>> on machine A:
>>>>>> *sudo ./tunnel.py --tx-freq=2.51G --rx-freq=2.515G -c 50 -r 0.5M *
>>>>>> then
>>>>>> *sudo ifconfig gr0 192.168.200.1*
>>>>>>
>>>>>> on machine B:
>>>>>> *sudo ./tunnel.py --tx-freq=2.515G --rx-freq=2.51G -c 50 -r 0.5M *
>>>>>> then
>>>>>> *sudo ifconfig gr0 192.168.200.2*
>>>>>>
>>>>>> I can see packages tx/rx succeed on both machines. But the ping
>>>>>> failed and one machine did not rx. Why is that?
>>>>>>
>>>>>> On Thu, Jun 14, 2012 at 4:38 PM, Alex Zhang 
>>>>>> wrote:
>>>>>>
>>>>>>> Most likely you did not set the freq and gain properly.  Unstable
>>>>>>> physical layer communications cause the ARP routing failure.
>>>>>>> Please use different frequencies for tx and rx.
>>>>>>>
>>>>>>> On Thu, Jun 14, 2012 at 1:51 PM, Weixian Zhou wrote:
>>>>>>>
>>>>>>>> I was testing with tunnel.py and following the instructions in
>>>>>>>> README located in gnuradio/gr-digital/examples/narrwoband.
>>>>>>>> I found that when I input* ifconfig gr0 192.168.200.1* on machine
>>>>>>>> A, and input* ifconfig gr0 192.168.200.2* on machine B at the same
>>>>>>>> time, both machines showed Tx and Rx packages.
>>>>>>>> But when I* ping 192.168.200.2* from machine A ( or *ping
>>>>>>>> 192.168.200.1* from machine B respectively), one window of machine
>>>>>>>> A only showed Tx packages and another window showed "Destination Host
>>>>>>>> Unreachable". Machine B showed both Rx/Tx packages.
>>>>>>>> It means that machine B can successfully received packages from
>>>>>>>> machine A but A failed to receive replied packages from machine B. It
>>>>>>>> confused me that the packages tx/rx were succeed before the ping. 
>>>>>>>> Anyone
>>>>>>>> has idea?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Weixian Zhou
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ___
>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>> Discuss-gnuradio@gnu.org
>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Alex,
>>>>>>> *Dreams can come true – just believe.*
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Weixian Zhou
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Alex,
>>>>> *Dreams can come true – just believe.*
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Weixian Zhou
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Alex,
>>> *Dreams can come true – just believe.*
>>>
>>>
>>
>>
>> --
>> Regards,
>> Weixian Zhou
>>
>>
>>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tunnel.py sends packages of incorrect size

[Alex Zhang]

42 is the length of the ARP request and make sure the other side sends out
ARP reply, otherwise, the Ping will always fail due to routing issue.

On Fri, Jun 15, 2012 at 9:31 AM, Weixian Zhou  wrote:

> I am doing test with tunnel.py and following the readme instructions
> located gnuradio/gr-digital/examples/narrowband.
> on machine A:
> *sudo ./tunnel.py --tx-freq=2.51G  --rx-freq=2.515G -c 50 -r 0.5M*
> then
> *sudo ifconfig gr0 192.168.200.1*
>
> on machine B:
> *sudo ./tunnel.py --tx-freq=2.515G  --rx-freq=2.51G -c 50 -r 0.5M*
> then
> *sudo ifconfig gr0 192.168.200.2*
>
> Then I can see packages tx/rx on both machines:
> *URx: ok = True len(payload) =   54*
> *Rx: ok = True  len(payload) =   90*
> *Rx: ok = True  len(payload) =  353*
> *Tx: len(payload) =   90*
> *Tx: len(payload) =   54*
> *...*
>
> After I ping from A to B, I found A only sends packages of fixed size 42:
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> ...
>
> But the default package size of ping is 56 from the man page. Where did
> the packages of size 42 come from? Anyone has idea?
> I am using two USRP N210s, the daughter boards are both XCVR2450.
>
> --
> Regards,
> Weixian Zhou
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tunnel.py destination host unreachable

[Alex Zhang]

Most likely you did not set the freq and gain properly.  Unstable physical
layer communications cause the ARP routing failure.
Please use different frequencies for tx and rx.

On Thu, Jun 14, 2012 at 1:51 PM, Weixian Zhou  wrote:

> I was testing with tunnel.py and following the instructions in README
> located in gnuradio/gr-digital/examples/narrwoband.
> I found that when I input* ifconfig gr0 192.168.200.1* on machine A, and
> input* ifconfig gr0 192.168.200.2* on machine B at the same time, both
> machines showed Tx and Rx packages.
> But when I* ping 192.168.200.2* from machine A ( or *ping 192.168.200.1*from 
> machine B respectively), one window of machine A only showed Tx
> packages and another window showed "Destination Host Unreachable". Machine
> B showed both Rx/Tx packages.
> It means that machine B can successfully received packages from machine A
> but A failed to receive replied packages from machine B. It confused me
> that the packages tx/rx were succeed before the ping. Anyone has idea?
>
> --
> Regards,
> Weixian Zhou
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio