Re: [USRP-users] (no subject)

[Marcus D Leech via USRP-users]

You’ll need to use timed commands for tuning, in order to phase align the LOs. 

Unfortunately there is no direct support for this in GRC. So you’ll have to 
edit the output code from GRC to change you tuning functions. 



Sent from my iPhone

> On Nov 13, 2020, at 8:08 AM, Arash Jafari via USRP-users 
>  wrote:
> 
> 
> Dear all,
> 
> I have an issue with the X310: when recording a CW signal at 430MHz with 
> gnuRadio (version3.8.2.0) the phase relation of the two channels is not 
> constant. Every time I start the recording (the same signal is applied) a 
> different phase is displayed. What is wrong with the setup?
> I have already tried to set the clock rate of the subdevice (2x UBX-160) to 
> 20MHz, it did not help.
>  
>  
> 
> 
> 
> 
> 
> 
> 
>  
> 
> Kind Regards
> - 
> Dipl.-Ing. Arash Jafari 
> 
> Phone: +43 650 844 3617
> E-mail: arash.jafari.tele...@gmail.com
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Michael Dickens via USRP-users]

Hi Rajesh - Sorry for the delay. Which branch / commit of gr-ieee802-11 are
you using? The version of GR is pretty old (3.7.6), and there's a
reasonable chance it's not compatible with the version of gr-ieee802-11 ...
but it could be something else too. Otherwise, yes, the settings you list
look fine. - MLD

On Tue, Sep 10, 2019 at 12:04 AM Dr. Rajesh Tiwari 
wrote:

> Hi Michael,
>
> Many thanks for all your answers, it really help as always. If I have
> understood correctly, here is the summary:
>
>- GRC is in default, i.e. /usr/local
>- PYTHONPATH /home/configure/usr/lib/python2.7/site-packages (this
>also means that Python is 27)
>- Using Python command, import ieee802_11
>- screenshot attached shows some import error in symbol
>
> I tried using export command and sudo ldconfig but nothing works, any
> advise please.
> Regards
> Rajesh
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Ron Economos via USRP-users]

Looks like you built the master branch of GNU Radio, which defaults to 
Python 3. To resolve those failing tests, you need python3-scipy and 
python3-zmq.


Ron

On 9/7/19 23:58, Dr. Rajesh Tiwari wrote:

Thanks Michael,

I removed and tried to install properly gnuradio, and I get the 
following test fail.

97% tests passed, 10 tests failed out of 364

Total Test time (real) = 237.56 sec

The following tests FAILED:
243 - qa_polar_decoder_sc (Failed)
244 - qa_polar_decoder_sc_list (Failed)
245 - qa_polar_decoder_sc_systematic (Failed)
246 - qa_polar_encoder (Failed)
247 - qa_polar_encoder_systematic (Failed)
360 - qa_zeromq_pub (Failed)
361 - qa_zeromq_pubsub (Failed)
362 - qa_zeromq_pushpull (Failed)
363 - qa_zeromq_reqrep (Failed)
364 - qa_zeromq_sub (Failed)
Errors while running CTest
Makefile:107: recipe for target 'test' failed
make: *** [test] Error 8

Any suggestion please. I tried to see some of the previous thread and 
suggested to install python-scipy which I did and sounds I have newest 
version. Please see below:

python-scipy is already the newest version (0.17.0-1).
The following packages were automatically installed and are no longer 
required:
  libcodec2-0.4 libcppunit-1.13-0v5 libcppunit-dev libglade2-0 
libglfw3 libgnuradio-analog3.7.9 libgnuradio-atsc3.7.9
  libgnuradio-channels3.7.9 libgnuradio-comedi3.7.9 
libgnuradio-digital3.7.9 libgnuradio-dtv3.7.9 libgnuradio-fec3.7.9 
libgnuradio-fft3.7.9
  libgnuradio-filter3.7.9 libgnuradio-fosphor3.7.0 
libgnuradio-noaa3.7.9 libgnuradio-pager3.7.9 libgnuradio-qtgui3.7.9
  libgnuradio-trellis3.7.9 libgnuradio-video-sdl3.7.9 
libgnuradio-vocoder3.7.9 libgnuradio-wavelet3.7.9 libgnuradio-wxgui3.7.9
  libgnuradio-zeromq3.7.9 libgsm1 libjs-jquery-ui libpython3-dev 
libpython3.5-dev libqwt-dev libqwt5-qt4 libqwt6abi1 libwxbase3.0-0v5
  libwxgtk3.0-0v5 python-bs4 python-cairo python-cheetah python-cycler 
python-dateutil python-glade2 python-gtk2 python-html5lib python-lxml
  python-matplotlib python-matplotlib-data python-networkx 
python-opengl python-pyparsing python-qwt5-qt4 python-tz python-wxgtk3.0

  python-wxversion python-yaml python3.5-dev rtl-sdr uhd-host
Use 'sudo apt autoremove' to remove them.
0 to upgrade, 0 to newly install, 0 to remove and 171 not to upgrade.

Regards
Rajesh

On Sat, Sep 7, 2019 at 7:46 PM Michael Dickens 
mailto:michael.dick...@ettus.com>> wrote:


Hi Rajesh - CMake found your GR38 install, not your GR37 install.
You should pick GR37 or GR38 and go with just it, and remove the
one you're not going with. Then, pick the same branch of
gr-ieee802-11. Hope this is useful! - MLD

On Sat, Sep 7, 2019 at 9:47 AM Dr. Rajesh Tiwari via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

Hi Ron,

Sounds good, seems a bit progress.
I think other than Cmake policy, attached in screenshot I am
almost there. Do you think I would need any other requirements?

Regards
Rajesh


On Sat, Sep 7, 2019 at 2:06 PM Ron Economos via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

Okay, here's the complete set of instructions.

git clone https://github.com/bastibl/gr-ieee802-11.git

cd gr-ieee802-11/

git checkout maint-3.7

mkdir build

cd build

cmake ../

make

sudo make install

sudo ldconfig

Make sure you use the correct install prefix in the cmake
step. You can determine the install prefix with:

gnuradio-config-info --prefix

cmake ../ will install into the default prefix, which is
usr/local. If you have any other prefix, you need to
specify that with the cmake command. For example:

cmake -DCMAKE_INSTALL_PREFIX=/usr ../

Ron

On 9/7/19 05:36, Dr. Rajesh Tiwari wrote:

Hi Ron,

Thanks for response. I think I am bit confused here..., I
am trying to install from
https://github.com/bastibl/gr-ieee802-11 and I am getting
error.

Regards
Rajesh

On Sat, Sep 7, 2019 at 12:07 PM Ron Economos via
USRP-users mailto:usrp-users@lists.ettus.com>> wrote:

Opps, should be:

git checkout maint-3.7

Ron

On 9/7/19 04:05, Ron Economos via USRP-users wrote:


There's a 3.7 version of gr-ieee802-11. In the
gr-ieee802-11 directory, type:

git checkout maint3.7

Ron

On 9/7/19 03:52, Dr. Rajesh Tiwari via USRP-users wrote:

HI Michael,

Many thanks for prompt response. I encountered
problem in installing module "gr-ieee802-11" as it
seems requiring gnuradio-companion, version 3.8. I
am not able to update 

Re: [USRP-users] (no subject)

[Dr. Rajesh Tiwari via USRP-users]

Thanks Michael,

I removed and tried to install properly gnuradio, and I get the following
test fail.
97% tests passed, 10 tests failed out of 364

Total Test time (real) = 237.56 sec

The following tests FAILED:
243 - qa_polar_decoder_sc (Failed)
244 - qa_polar_decoder_sc_list (Failed)
245 - qa_polar_decoder_sc_systematic (Failed)
246 - qa_polar_encoder (Failed)
247 - qa_polar_encoder_systematic (Failed)
360 - qa_zeromq_pub (Failed)
361 - qa_zeromq_pubsub (Failed)
362 - qa_zeromq_pushpull (Failed)
363 - qa_zeromq_reqrep (Failed)
364 - qa_zeromq_sub (Failed)
Errors while running CTest
Makefile:107: recipe for target 'test' failed
make: *** [test] Error 8

Any suggestion please. I tried to see some of the previous thread and
suggested to install python-scipy which I did and sounds I have newest
version. Please see below:
python-scipy is already the newest version (0.17.0-1).
The following packages were automatically installed and are no longer
required:
  libcodec2-0.4 libcppunit-1.13-0v5 libcppunit-dev libglade2-0 libglfw3
libgnuradio-analog3.7.9 libgnuradio-atsc3.7.9
  libgnuradio-channels3.7.9 libgnuradio-comedi3.7.9
libgnuradio-digital3.7.9 libgnuradio-dtv3.7.9 libgnuradio-fec3.7.9
libgnuradio-fft3.7.9
  libgnuradio-filter3.7.9 libgnuradio-fosphor3.7.0 libgnuradio-noaa3.7.9
libgnuradio-pager3.7.9 libgnuradio-qtgui3.7.9
  libgnuradio-trellis3.7.9 libgnuradio-video-sdl3.7.9
libgnuradio-vocoder3.7.9 libgnuradio-wavelet3.7.9 libgnuradio-wxgui3.7.9
  libgnuradio-zeromq3.7.9 libgsm1 libjs-jquery-ui libpython3-dev
libpython3.5-dev libqwt-dev libqwt5-qt4 libqwt6abi1 libwxbase3.0-0v5
  libwxgtk3.0-0v5 python-bs4 python-cairo python-cheetah python-cycler
python-dateutil python-glade2 python-gtk2 python-html5lib python-lxml
  python-matplotlib python-matplotlib-data python-networkx python-opengl
python-pyparsing python-qwt5-qt4 python-tz python-wxgtk3.0
  python-wxversion python-yaml python3.5-dev rtl-sdr uhd-host
Use 'sudo apt autoremove' to remove them.
0 to upgrade, 0 to newly install, 0 to remove and 171 not to upgrade.

Regards
Rajesh

On Sat, Sep 7, 2019 at 7:46 PM Michael Dickens 
wrote:

> Hi Rajesh - CMake found your GR38 install, not your GR37 install. You
> should pick GR37 or GR38 and go with just it, and remove the one you're not
> going with. Then, pick the same branch of gr-ieee802-11. Hope this is
> useful! - MLD
>
> On Sat, Sep 7, 2019 at 9:47 AM Dr. Rajesh Tiwari via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Ron,
>>
>> Sounds good, seems a bit progress.
>> I think other than Cmake policy, attached in screenshot I am almost
>> there. Do you think I would need any other requirements?
>>
>> Regards
>> Rajesh
>>
>>
>> On Sat, Sep 7, 2019 at 2:06 PM Ron Economos via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Okay, here's the complete set of instructions.
>>>
>>> git clone https://github.com/bastibl/gr-ieee802-11.git
>>>
>>> cd gr-ieee802-11/
>>>
>>> git checkout maint-3.7
>>>
>>> mkdir build
>>>
>>> cd build
>>>
>>> cmake ../
>>>
>>> make
>>>
>>> sudo make install
>>>
>>> sudo ldconfig
>>>
>>> Make sure you use the correct install prefix in the cmake step. You can
>>> determine the install prefix with:
>>>
>>> gnuradio-config-info --prefix
>>>
>>> cmake ../ will install into the default prefix, which is usr/local. If
>>> you have any other prefix, you need to specify that with the cmake command.
>>> For example:
>>>
>>> cmake -DCMAKE_INSTALL_PREFIX=/usr ../
>>>
>>> Ron
>>> On 9/7/19 05:36, Dr. Rajesh Tiwari wrote:
>>>
>>> Hi Ron,
>>>
>>> Thanks for response. I think I am bit confused here..., I am trying to
>>> install from https://github.com/bastibl/gr-ieee802-11 and I am getting
>>> error.
>>>
>>> Regards
>>> Rajesh
>>>
>>> On Sat, Sep 7, 2019 at 12:07 PM Ron Economos via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Opps, should be:

 git checkout maint-3.7

 Ron
 On 9/7/19 04:05, Ron Economos via USRP-users wrote:

 There's a 3.7 version of gr-ieee802-11. In the gr-ieee802-11 directory,
 type:

 git checkout maint3.7

 Ron
 On 9/7/19 03:52, Dr. Rajesh Tiwari via USRP-users wrote:

 HI Michael,

 Many thanks for prompt response. I encountered problem in installing
 module "gr-ieee802-11" as it seems requiring gnuradio-companion, version
 3.8. I am not able to update my GRC version 3.7 to 3.8. Any suggestion,
 please let me know.

 Regards
 Rajesh

 On Fri, Sep 6, 2019 at 5:14 PM Michael Dickens <
 michael.dick...@ettus.com> wrote:

> Hi Rajesh - The block "OFDM Sync Short" is part of the GR out-of-tree
> (OOT) module "gr-ieee802-11" ... as are many of the other blocks in the
> image you provided. If that OOT is not installed already, it shouldn't be
> difficult to do so. Hope this is useful! - MLD
>
> On Fri, Sep 6, 2019 at 5:10 AM Dr. Rajesh Tiwari via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> 

Re: [USRP-users] (no subject)

[Michael Dickens via USRP-users]

Hi Rajesh - CMake found your GR38 install, not your GR37 install. You
should pick GR37 or GR38 and go with just it, and remove the one you're not
going with. Then, pick the same branch of gr-ieee802-11. Hope this is
useful! - MLD

On Sat, Sep 7, 2019 at 9:47 AM Dr. Rajesh Tiwari via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Ron,
>
> Sounds good, seems a bit progress.
> I think other than Cmake policy, attached in screenshot I am almost there.
> Do you think I would need any other requirements?
>
> Regards
> Rajesh
>
>
> On Sat, Sep 7, 2019 at 2:06 PM Ron Economos via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Okay, here's the complete set of instructions.
>>
>> git clone https://github.com/bastibl/gr-ieee802-11.git
>>
>> cd gr-ieee802-11/
>>
>> git checkout maint-3.7
>>
>> mkdir build
>>
>> cd build
>>
>> cmake ../
>>
>> make
>>
>> sudo make install
>>
>> sudo ldconfig
>>
>> Make sure you use the correct install prefix in the cmake step. You can
>> determine the install prefix with:
>>
>> gnuradio-config-info --prefix
>>
>> cmake ../ will install into the default prefix, which is usr/local. If
>> you have any other prefix, you need to specify that with the cmake command.
>> For example:
>>
>> cmake -DCMAKE_INSTALL_PREFIX=/usr ../
>>
>> Ron
>> On 9/7/19 05:36, Dr. Rajesh Tiwari wrote:
>>
>> Hi Ron,
>>
>> Thanks for response. I think I am bit confused here..., I am trying to
>> install from https://github.com/bastibl/gr-ieee802-11 and I am getting
>> error.
>>
>> Regards
>> Rajesh
>>
>> On Sat, Sep 7, 2019 at 12:07 PM Ron Economos via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Opps, should be:
>>>
>>> git checkout maint-3.7
>>>
>>> Ron
>>> On 9/7/19 04:05, Ron Economos via USRP-users wrote:
>>>
>>> There's a 3.7 version of gr-ieee802-11. In the gr-ieee802-11 directory,
>>> type:
>>>
>>> git checkout maint3.7
>>>
>>> Ron
>>> On 9/7/19 03:52, Dr. Rajesh Tiwari via USRP-users wrote:
>>>
>>> HI Michael,
>>>
>>> Many thanks for prompt response. I encountered problem in installing
>>> module "gr-ieee802-11" as it seems requiring gnuradio-companion, version
>>> 3.8. I am not able to update my GRC version 3.7 to 3.8. Any suggestion,
>>> please let me know.
>>>
>>> Regards
>>> Rajesh
>>>
>>> On Fri, Sep 6, 2019 at 5:14 PM Michael Dickens <
>>> michael.dick...@ettus.com> wrote:
>>>
 Hi Rajesh - The block "OFDM Sync Short" is part of the GR out-of-tree
 (OOT) module "gr-ieee802-11" ... as are many of the other blocks in the
 image you provided. If that OOT is not installed already, it shouldn't be
 difficult to do so. Hope this is useful! - MLD

 On Fri, Sep 6, 2019 at 5:10 AM Dr. Rajesh Tiwari via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Dear All,
>
> I am trying to decode IEEE 802.11a OFDM receiver as per GRC block
> diagram used in Paper "Bloessl et al(2013), An IEEE 802.11a/g/p OFDM
> Receiver for GNU Radio, SRIF’13, August 12, 2013, Hong Kong, China.". The
> screenshot of block diagram given below, In GRC, I didn't find "OFDM Sync
> Short" block, any help would be appreciated.
>
> "GRC block diagram from Bloessl et al(2013), An IEEE 802.11a/g/p OFDM
> Receiver for GNU Radio, SRIF’13, August 12, 2013, Hong Kong, China"
>
> Regards
> Rajesh
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

 --
 Michael Dickens, Mac OS X Programmer

 Ettus Research Technical Support

 Email: supp...@ettus.com

 Web: http://www.ettus.com

>>>
>>> ___
>>> USRP-users mailing 
>>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>> ___
>>> USRP-users mailing 
>>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Ron Economos via USRP-users]

Okay, here's the complete set of instructions.

git clone https://github.com/bastibl/gr-ieee802-11.git

cd gr-ieee802-11/

git checkout maint-3.7

mkdir build

cd build

cmake ../

make

sudo make install

sudo ldconfig

Make sure you use the correct install prefix in the cmake step. You can 
determine the install prefix with:


gnuradio-config-info --prefix

cmake ../ will install into the default prefix, which is usr/local. If 
you have any other prefix, you need to specify that with the cmake 
command. For example:


cmake -DCMAKE_INSTALL_PREFIX=/usr ../

Ron

On 9/7/19 05:36, Dr. Rajesh Tiwari wrote:

Hi Ron,

Thanks for response. I think I am bit confused here..., I am trying to 
install from https://github.com/bastibl/gr-ieee802-11 and I am getting 
error.


Regards
Rajesh

On Sat, Sep 7, 2019 at 12:07 PM Ron Economos via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Opps, should be:

git checkout maint-3.7

Ron

On 9/7/19 04:05, Ron Economos via USRP-users wrote:


There's a 3.7 version of gr-ieee802-11. In the gr-ieee802-11
directory, type:

git checkout maint3.7

Ron

On 9/7/19 03:52, Dr. Rajesh Tiwari via USRP-users wrote:

HI Michael,

Many thanks for prompt response. I encountered problem in
installing module "gr-ieee802-11" as it seems requiring
gnuradio-companion, version 3.8. I am not able to update my GRC
version 3.7 to 3.8. Any suggestion, please let me know.

Regards
Rajesh

On Fri, Sep 6, 2019 at 5:14 PM Michael Dickens
mailto:michael.dick...@ettus.com>>
wrote:

Hi Rajesh - The block "OFDM Sync Short" is part of the GR
out-of-tree (OOT) module "gr-ieee802-11" ... as are many of
the other blocks in the image you provided. If that OOT is
not installed already, it shouldn't be difficult to do so.
Hope this is useful! - MLD

On Fri, Sep 6, 2019 at 5:10 AM Dr. Rajesh Tiwari via
USRP-users mailto:usrp-users@lists.ettus.com>> wrote:

Dear All,

I am trying to decode IEEE 802.11a OFDM receiver as per
GRC block diagram used in Paper "Bloessl et al(2013), An
IEEE 802.11a/g/p OFDM Receiver for GNU Radio, SRIF’13,
August 12, 2013, Hong Kong, China.". The screenshot of
block diagram given below, In GRC, I didn't find "OFDM
Sync Short" block, any help would be appreciated.

"GRC block diagram from Bloessl et al(2013), An IEEE
802.11a/g/p OFDM Receiver for GNU Radio, SRIF’13, August
12, 2013, Hong Kong, China"

Regards
Rajesh

___
USRP-users mailing list
USRP-users@lists.ettus.com

http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


-- 
Michael Dickens, Mac OS X Programmer


Ettus Research Technical Support

Email: supp...@ettus.com 

Web: http://www.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com  
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com  
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Dr. Rajesh Tiwari via USRP-users]

Hi Ron,

Thanks for response. I think I am bit confused here..., I am trying to
install from https://github.com/bastibl/gr-ieee802-11 and I am getting
error.

Regards
Rajesh

On Sat, Sep 7, 2019 at 12:07 PM Ron Economos via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Opps, should be:
>
> git checkout maint-3.7
>
> Ron
> On 9/7/19 04:05, Ron Economos via USRP-users wrote:
>
> There's a 3.7 version of gr-ieee802-11. In the gr-ieee802-11 directory,
> type:
>
> git checkout maint3.7
>
> Ron
> On 9/7/19 03:52, Dr. Rajesh Tiwari via USRP-users wrote:
>
> HI Michael,
>
> Many thanks for prompt response. I encountered problem in installing
> module "gr-ieee802-11" as it seems requiring gnuradio-companion, version
> 3.8. I am not able to update my GRC version 3.7 to 3.8. Any suggestion,
> please let me know.
>
> Regards
> Rajesh
>
> On Fri, Sep 6, 2019 at 5:14 PM Michael Dickens 
> wrote:
>
>> Hi Rajesh - The block "OFDM Sync Short" is part of the GR out-of-tree
>> (OOT) module "gr-ieee802-11" ... as are many of the other blocks in the
>> image you provided. If that OOT is not installed already, it shouldn't be
>> difficult to do so. Hope this is useful! - MLD
>>
>> On Fri, Sep 6, 2019 at 5:10 AM Dr. Rajesh Tiwari via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Dear All,
>>>
>>> I am trying to decode IEEE 802.11a OFDM receiver as per GRC block
>>> diagram used in Paper "Bloessl et al(2013), An IEEE 802.11a/g/p OFDM
>>> Receiver for GNU Radio, SRIF’13, August 12, 2013, Hong Kong, China.". The
>>> screenshot of block diagram given below, In GRC, I didn't find "OFDM Sync
>>> Short" block, any help would be appreciated.
>>>
>>> "GRC block diagram from Bloessl et al(2013), An IEEE 802.11a/g/p OFDM
>>> Receiver for GNU Radio, SRIF’13, August 12, 2013, Hong Kong, China"
>>>
>>> Regards
>>> Rajesh
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> --
>> Michael Dickens, Mac OS X Programmer
>>
>> Ettus Research Technical Support
>>
>> Email: supp...@ettus.com
>>
>> Web: http://www.ettus.com
>>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Ron Economos via USRP-users]

Opps, should be:

git checkout maint-3.7

Ron

On 9/7/19 04:05, Ron Economos via USRP-users wrote:


There's a 3.7 version of gr-ieee802-11. In the gr-ieee802-11 
directory, type:


git checkout maint3.7

Ron

On 9/7/19 03:52, Dr. Rajesh Tiwari via USRP-users wrote:

HI Michael,

Many thanks for prompt response. I encountered problem in installing 
module "gr-ieee802-11" as it seems requiring gnuradio-companion, 
version 3.8. I am not able to update my GRC version 3.7 to 3.8. Any 
suggestion, please let me know.


Regards
Rajesh

On Fri, Sep 6, 2019 at 5:14 PM Michael Dickens 
mailto:michael.dick...@ettus.com>> wrote:


Hi Rajesh - The block "OFDM Sync Short" is part of the GR
out-of-tree (OOT) module "gr-ieee802-11" ... as are many of the
other blocks in the image you provided. If that OOT is not
installed already, it shouldn't be difficult to do so. Hope this
is useful! - MLD

On Fri, Sep 6, 2019 at 5:10 AM Dr. Rajesh Tiwari via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

Dear All,

I am trying to decode IEEE 802.11a OFDM receiver as per GRC
block diagram used in Paper "Bloessl et al(2013), An IEEE
802.11a/g/p OFDM Receiver for GNU Radio, SRIF’13, August 12,
2013, Hong Kong, China.". The screenshot of block diagram
given below, In GRC, I didn't find "OFDM Sync Short" block,
any help would be appreciated.

"GRC block diagram from Bloessl et al(2013), An IEEE
802.11a/g/p OFDM Receiver for GNU Radio, SRIF’13, August 12,
2013, Hong Kong, China"

Regards
Rajesh

___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


-- 
Michael Dickens, Mac OS X Programmer


Ettus Research Technical Support

Email: supp...@ettus.com 

Web: http://www.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Ron Economos via USRP-users]

There's a 3.7 version of gr-ieee802-11. In the gr-ieee802-11 directory, 
type:


git checkout maint3.7

Ron

On 9/7/19 03:52, Dr. Rajesh Tiwari via USRP-users wrote:

HI Michael,

Many thanks for prompt response. I encountered problem in installing 
module "gr-ieee802-11" as it seems requiring gnuradio-companion, 
version 3.8. I am not able to update my GRC version 3.7 to 3.8. Any 
suggestion, please let me know.


Regards
Rajesh

On Fri, Sep 6, 2019 at 5:14 PM Michael Dickens 
mailto:michael.dick...@ettus.com>> wrote:


Hi Rajesh - The block "OFDM Sync Short" is part of the GR
out-of-tree (OOT) module "gr-ieee802-11" ... as are many of the
other blocks in the image you provided. If that OOT is not
installed already, it shouldn't be difficult to do so. Hope this
is useful! - MLD

On Fri, Sep 6, 2019 at 5:10 AM Dr. Rajesh Tiwari via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

Dear All,

I am trying to decode IEEE 802.11a OFDM receiver as per GRC
block diagram used in Paper "Bloessl et al(2013), An IEEE
802.11a/g/p OFDM Receiver for GNU Radio, SRIF’13, August 12,
2013, Hong Kong, China.". The screenshot of block diagram
given below, In GRC, I didn't find "OFDM Sync Short" block,
any help would be appreciated.

"GRC block diagram from Bloessl et al(2013), An IEEE
802.11a/g/p OFDM Receiver for GNU Radio, SRIF’13, August 12,
2013, Hong Kong, China"

Regards
Rajesh

___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


-- 
Michael Dickens, Mac OS X Programmer


Ettus Research Technical Support

Email: supp...@ettus.com 

Web: http://www.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Dr. Rajesh Tiwari via USRP-users]

HI Michael,

Many thanks for prompt response. I encountered problem in installing module
"gr-ieee802-11" as it seems requiring gnuradio-companion, version 3.8. I am
not able to update my GRC version 3.7 to 3.8. Any suggestion, please let me
know.

Regards
Rajesh

On Fri, Sep 6, 2019 at 5:14 PM Michael Dickens 
wrote:

> Hi Rajesh - The block "OFDM Sync Short" is part of the GR out-of-tree
> (OOT) module "gr-ieee802-11" ... as are many of the other blocks in the
> image you provided. If that OOT is not installed already, it shouldn't be
> difficult to do so. Hope this is useful! - MLD
>
> On Fri, Sep 6, 2019 at 5:10 AM Dr. Rajesh Tiwari via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear All,
>>
>> I am trying to decode IEEE 802.11a OFDM receiver as per GRC block diagram
>> used in Paper "Bloessl et al(2013), An IEEE 802.11a/g/p OFDM Receiver for
>> GNU Radio, SRIF’13, August 12, 2013, Hong Kong, China.". The screenshot of
>> block diagram given below, In GRC, I didn't find "OFDM Sync Short" block,
>> any help would be appreciated.
>>
>> "GRC block diagram from Bloessl et al(2013), An IEEE 802.11a/g/p OFDM
>> Receiver for GNU Radio, SRIF’13, August 12, 2013, Hong Kong, China"
>>
>> Regards
>> Rajesh
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> --
> Michael Dickens, Mac OS X Programmer
>
> Ettus Research Technical Support
>
> Email: supp...@ettus.com
>
> Web: http://www.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Michael Dickens via USRP-users]

Hi Rajesh - The block "OFDM Sync Short" is part of the GR out-of-tree (OOT)
module "gr-ieee802-11" ... as are many of the other blocks in the image you
provided. If that OOT is not installed already, it shouldn't be difficult
to do so. Hope this is useful! - MLD

On Fri, Sep 6, 2019 at 5:10 AM Dr. Rajesh Tiwari via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear All,
>
> I am trying to decode IEEE 802.11a OFDM receiver as per GRC block diagram
> used in Paper "Bloessl et al(2013), An IEEE 802.11a/g/p OFDM Receiver for
> GNU Radio, SRIF’13, August 12, 2013, Hong Kong, China.". The screenshot of
> block diagram given below, In GRC, I didn't find "OFDM Sync Short" block,
> any help would be appreciated.
>
> "GRC block diagram from Bloessl et al(2013), An IEEE 802.11a/g/p OFDM
> Receiver for GNU Radio, SRIF’13, August 12, 2013, Hong Kong, China"
>
> Regards
> Rajesh
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[John Medrano via USRP-users]

Adding library in CMakeList.txt and setting environment variable
LD_PRELOAD=/usr/local/lib/"my lib" fixed the original problem.

I did not have to set --whole-archive option.

Thank you.


On Tue, Apr 16, 2019 at 12:33 PM Nick Foster  wrote:

> Just wanted to follow up on this, because I thought of something in the
> shower this morning.
>
> If you compile your block controller as a shared library and you want your
> block to be initialized/used with the default UHD apps, you can use
> LD_PRELOAD to ensure the block registration happens at runtime. For
> instance:
>
> $ LD_PRELOAD=/usr/local/lib/librfnoc-clabs.so uhd_usrp_probe
> --args=addr=192.168.10.2
>
> ...if your RFNoC controller is registered inside that .so, it will be
> loaded and registered for uhd_usrp_probe.
>
> Just a helpful trick if you want to (for instance) use rfnoc_rx_to_file to
> test your block, since it has the option to specify a custom block to
> insert between the radio and the host.
>
> Nick
>
> On Tue, Apr 9, 2019 at 10:51 AM John Medrano 
> wrote:
>
>> Thank you.
>>
>> Using:
>>
>> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
>> -Wl,--no-whole-archive)
>> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
>> your libs...>)
>>
>> We are able to use our controller.
>>
>> On Mon, Apr 8, 2019 at 11:52 AM Nick Foster  wrote:
>>
>>> OK, I looked further into it. UHD registers out-of-tree block
>>> controllers using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood
>>> creates a static function and a fixture which calls it before main().
>>> Problem is, when linking your out-of-tree executable, the linker sees that
>>> the static fixture is never explicitly called from your program, and it
>>> optimizes it out. So your block is never getting registered.
>>>
>>> There's a number of ways to fix it. I don't know how UHD does it
>>> internally. If you are linking your library statically, you can do
>>> something like the following in the CMakeLists.txt for the application (not
>>> the library):
>>>
>>> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
>>> -Wl,--no-whole-archive)
>>> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
>>> your libs...>)
>>>
>>> Using --whole-archive will force the linker to include all the contents
>>> of your custom static lib in the application. This includes the static
>>> constructor.
>>>
>>> If you're linking dynamically, this may or may not be a problem for you.
>>> If it is, you can do something like
>>> set_target_properties(rfnoc_myapp PROPERTIES LINK_WHAT_YOU_USE TRUE)
>>>
>>> ...which sets the -Wl,--no-as-needed linker flag, indicating to the
>>> linker that it should include dynamic libraries that aren't explicitly
>>> called. This isn't a great solution as it can result in linking to
>>> libraries which really aren't used.
>>>
>>> You can debug this approach by calling the UHD_STATIC_BLOCK macro in
>>> your library and just having it print something to stdout. If you don't see
>>> the print in your application, it's not linking static objects correctly.
>>>
>>> Nick
>>>
>>> On Mon, Apr 8, 2019 at 8:24 AM John Medrano 
>>> wrote:
>>>
 Hello,

 We have verified that library is being linked.

 When we run  nm  | grep 

 We see the following:
 00030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19>>> name>_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
 0023d6e0 V _ZTIN3uhd5rfnoc19_block_ctrlE
 00034b00 V _ZTSN3uhd5rfnoc19_ctrlE

 We continue to get same error.

 We have several blocks and we tried with all of them with same result.


 On Wed, Mar 27, 2019 at 4:36 PM Nick Foster 
 wrote:

> Make very sure that your program is actually linking in the library
> correctly. Linkers are weird and their interaction with build systems is
> often unpredictable and sometimes perverse. Find the symbols in the
> compiled library with nm and see that they aren't undefined. Use make
> VERBOSE=1 to see the library actually being used.
>
> Nick
>
> On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
> wrote:
>
>> Thank you for the response.
>>
>> I have added to CMakeList.txt:
>>
>> find_library(SLADEW_LIB gnuradio-SLADEW)
>> if(NOT SLADEW_LIB)
>>   message(FATAL_ERROR "SLADEW library not found")
>> endif()
>>
>> add later I add:
>>
>> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES}
>> ${Boost_LIBRARIES} ${SLADEW_LIB})
>>
>> It compiles fine but I still get same messages on start up.
>>
>> Please advise:
>> John
>>
>>
>> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster 
>> wrote:
>>
>>> Your program needs to be linked against the library which your
>>> custom block controller is compiled into, if in fact your block is 
>>> using a
>>> custom block controller.
>>>
>>> uhd_usrp_probe and 

Re: [USRP-users] (no subject)

[Nick Foster via USRP-users]

Just wanted to follow up on this, because I thought of something in the
shower this morning.

If you compile your block controller as a shared library and you want your
block to be initialized/used with the default UHD apps, you can use
LD_PRELOAD to ensure the block registration happens at runtime. For
instance:

$ LD_PRELOAD=/usr/local/lib/librfnoc-clabs.so uhd_usrp_probe
--args=addr=192.168.10.2

...if your RFNoC controller is registered inside that .so, it will be
loaded and registered for uhd_usrp_probe.

Just a helpful trick if you want to (for instance) use rfnoc_rx_to_file to
test your block, since it has the option to specify a custom block to
insert between the radio and the host.

Nick

On Tue, Apr 9, 2019 at 10:51 AM John Medrano 
wrote:

> Thank you.
>
> Using:
>
> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
> -Wl,--no-whole-archive)
> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
> your libs...>)
>
> We are able to use our controller.
>
> On Mon, Apr 8, 2019 at 11:52 AM Nick Foster  wrote:
>
>> OK, I looked further into it. UHD registers out-of-tree block controllers
>> using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood creates a
>> static function and a fixture which calls it before main(). Problem is,
>> when linking your out-of-tree executable, the linker sees that the static
>> fixture is never explicitly called from your program, and it optimizes it
>> out. So your block is never getting registered.
>>
>> There's a number of ways to fix it. I don't know how UHD does it
>> internally. If you are linking your library statically, you can do
>> something like the following in the CMakeLists.txt for the application (not
>> the library):
>>
>> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
>> -Wl,--no-whole-archive)
>> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
>> your libs...>)
>>
>> Using --whole-archive will force the linker to include all the contents
>> of your custom static lib in the application. This includes the static
>> constructor.
>>
>> If you're linking dynamically, this may or may not be a problem for you.
>> If it is, you can do something like
>> set_target_properties(rfnoc_myapp PROPERTIES LINK_WHAT_YOU_USE TRUE)
>>
>> ...which sets the -Wl,--no-as-needed linker flag, indicating to the
>> linker that it should include dynamic libraries that aren't explicitly
>> called. This isn't a great solution as it can result in linking to
>> libraries which really aren't used.
>>
>> You can debug this approach by calling the UHD_STATIC_BLOCK macro in your
>> library and just having it print something to stdout. If you don't see the
>> print in your application, it's not linking static objects correctly.
>>
>> Nick
>>
>> On Mon, Apr 8, 2019 at 8:24 AM John Medrano 
>> wrote:
>>
>>> Hello,
>>>
>>> We have verified that library is being linked.
>>>
>>> When we run  nm  | grep 
>>>
>>> We see the following:
>>> 00030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19>> name>_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
>>> 0023d6e0 V _ZTIN3uhd5rfnoc19_block_ctrlE
>>> 00034b00 V _ZTSN3uhd5rfnoc19_ctrlE
>>>
>>> We continue to get same error.
>>>
>>> We have several blocks and we tried with all of them with same result.
>>>
>>>
>>> On Wed, Mar 27, 2019 at 4:36 PM Nick Foster 
>>> wrote:
>>>
 Make very sure that your program is actually linking in the library
 correctly. Linkers are weird and their interaction with build systems is
 often unpredictable and sometimes perverse. Find the symbols in the
 compiled library with nm and see that they aren't undefined. Use make
 VERBOSE=1 to see the library actually being used.

 Nick

 On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
 wrote:

> Thank you for the response.
>
> I have added to CMakeList.txt:
>
> find_library(SLADEW_LIB gnuradio-SLADEW)
> if(NOT SLADEW_LIB)
>   message(FATAL_ERROR "SLADEW library not found")
> endif()
>
> add later I add:
>
> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES}
> ${Boost_LIBRARIES} ${SLADEW_LIB})
>
> It compiles fine but I still get same messages on start up.
>
> Please advise:
> John
>
>
> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster 
> wrote:
>
>> Your program needs to be linked against the library which your custom
>> block controller is compiled into, if in fact your block is using a 
>> custom
>> block controller.
>>
>> uhd_usrp_probe and the other UHD utilities aren't linked against the
>> custom library. This isn't generally a problem since the utilities and
>> examples don't make use of your custom block.
>>
>> Nick
>>
>> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> We have a custom RFNOC block that we 

Re: [USRP-users] (no subject)

[John Medrano via USRP-users]

Thank you.

Using:

set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
-Wl,--no-whole-archive)
target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
your libs...>)

We are able to use our controller.

On Mon, Apr 8, 2019 at 11:52 AM Nick Foster  wrote:

> OK, I looked further into it. UHD registers out-of-tree block controllers
> using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood creates a
> static function and a fixture which calls it before main(). Problem is,
> when linking your out-of-tree executable, the linker sees that the static
> fixture is never explicitly called from your program, and it optimizes it
> out. So your block is never getting registered.
>
> There's a number of ways to fix it. I don't know how UHD does it
> internally. If you are linking your library statically, you can do
> something like the following in the CMakeLists.txt for the application (not
> the library):
>
> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
> -Wl,--no-whole-archive)
> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
> your libs...>)
>
> Using --whole-archive will force the linker to include all the contents of
> your custom static lib in the application. This includes the static
> constructor.
>
> If you're linking dynamically, this may or may not be a problem for you.
> If it is, you can do something like
> set_target_properties(rfnoc_myapp PROPERTIES LINK_WHAT_YOU_USE TRUE)
>
> ...which sets the -Wl,--no-as-needed linker flag, indicating to the linker
> that it should include dynamic libraries that aren't explicitly called.
> This isn't a great solution as it can result in linking to libraries which
> really aren't used.
>
> You can debug this approach by calling the UHD_STATIC_BLOCK macro in your
> library and just having it print something to stdout. If you don't see the
> print in your application, it's not linking static objects correctly.
>
> Nick
>
> On Mon, Apr 8, 2019 at 8:24 AM John Medrano 
> wrote:
>
>> Hello,
>>
>> We have verified that library is being linked.
>>
>> When we run  nm  | grep 
>>
>> We see the following:
>> 00030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19> name>_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
>> 0023d6e0 V _ZTIN3uhd5rfnoc19_block_ctrlE
>> 00034b00 V _ZTSN3uhd5rfnoc19_ctrlE
>>
>> We continue to get same error.
>>
>> We have several blocks and we tried with all of them with same result.
>>
>>
>> On Wed, Mar 27, 2019 at 4:36 PM Nick Foster  wrote:
>>
>>> Make very sure that your program is actually linking in the library
>>> correctly. Linkers are weird and their interaction with build systems is
>>> often unpredictable and sometimes perverse. Find the symbols in the
>>> compiled library with nm and see that they aren't undefined. Use make
>>> VERBOSE=1 to see the library actually being used.
>>>
>>> Nick
>>>
>>> On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
>>> wrote:
>>>
 Thank you for the response.

 I have added to CMakeList.txt:

 find_library(SLADEW_LIB gnuradio-SLADEW)
 if(NOT SLADEW_LIB)
   message(FATAL_ERROR "SLADEW library not found")
 endif()

 add later I add:

 target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES} ${Boost_LIBRARIES}
 ${SLADEW_LIB})

 It compiles fine but I still get same messages on start up.

 Please advise:
 John


 On Wed, Mar 27, 2019 at 3:00 PM Nick Foster 
 wrote:

> Your program needs to be linked against the library which your custom
> block controller is compiled into, if in fact your block is using a custom
> block controller.
>
> uhd_usrp_probe and the other UHD utilities aren't linked against the
> custom library. This isn't generally a problem since the utilities and
> examples don't make use of your custom block.
>
> Nick
>
> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello,
>>
>> We have a custom RFNOC block that we have created. When we using
>> GNURadio/Python everything works fine. When follow the examples in
>> uhd/host/examples and generate an executable using C++, we get an error 
>> on
>> execution.
>>
>> We noticed that on start up the python program has no issue locating
>> controllers for all our custom blocks (FreqMod):
>>
>> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux;
>> GNU C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
>> 2019-Mar-27
>> 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300 
>> initialization
>> sequence...
>> 2019-Mar-27
>> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
>> size: 1472 bytes.
>> 2019-Mar-27
>> 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio 1x clock: 
>> 200
>> MHz
>> 2019-Mar-27
>> 

Re: [USRP-users] (no subject)

[Nick Foster via USRP-users]

OK, I looked further into it. UHD registers out-of-tree block controllers
using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood creates a
static function and a fixture which calls it before main(). Problem is,
when linking your out-of-tree executable, the linker sees that the static
fixture is never explicitly called from your program, and it optimizes it
out. So your block is never getting registered.

There's a number of ways to fix it. I don't know how UHD does it
internally. If you are linking your library statically, you can do
something like the following in the CMakeLists.txt for the application (not
the library):

set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
-Wl,--no-whole-archive)
target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
your libs...>)

Using --whole-archive will force the linker to include all the contents of
your custom static lib in the application. This includes the static
constructor.

If you're linking dynamically, this may or may not be a problem for you. If
it is, you can do something like
set_target_properties(rfnoc_myapp PROPERTIES LINK_WHAT_YOU_USE TRUE)

...which sets the -Wl,--no-as-needed linker flag, indicating to the linker
that it should include dynamic libraries that aren't explicitly called.
This isn't a great solution as it can result in linking to libraries which
really aren't used.

You can debug this approach by calling the UHD_STATIC_BLOCK macro in your
library and just having it print something to stdout. If you don't see the
print in your application, it's not linking static objects correctly.

Nick

On Mon, Apr 8, 2019 at 8:24 AM John Medrano 
wrote:

> Hello,
>
> We have verified that library is being linked.
>
> When we run  nm  | grep 
>
> We see the following:
> 00030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19 name>_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
> 0023d6e0 V _ZTIN3uhd5rfnoc19_block_ctrlE
> 00034b00 V _ZTSN3uhd5rfnoc19_ctrlE
>
> We continue to get same error.
>
> We have several blocks and we tried with all of them with same result.
>
>
> On Wed, Mar 27, 2019 at 4:36 PM Nick Foster  wrote:
>
>> Make very sure that your program is actually linking in the library
>> correctly. Linkers are weird and their interaction with build systems is
>> often unpredictable and sometimes perverse. Find the symbols in the
>> compiled library with nm and see that they aren't undefined. Use make
>> VERBOSE=1 to see the library actually being used.
>>
>> Nick
>>
>> On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
>> wrote:
>>
>>> Thank you for the response.
>>>
>>> I have added to CMakeList.txt:
>>>
>>> find_library(SLADEW_LIB gnuradio-SLADEW)
>>> if(NOT SLADEW_LIB)
>>>   message(FATAL_ERROR "SLADEW library not found")
>>> endif()
>>>
>>> add later I add:
>>>
>>> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES} ${Boost_LIBRARIES}
>>> ${SLADEW_LIB})
>>>
>>> It compiles fine but I still get same messages on start up.
>>>
>>> Please advise:
>>> John
>>>
>>>
>>> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster 
>>> wrote:
>>>
 Your program needs to be linked against the library which your custom
 block controller is compiled into, if in fact your block is using a custom
 block controller.

 uhd_usrp_probe and the other UHD utilities aren't linked against the
 custom library. This isn't generally a problem since the utilities and
 examples don't make use of your custom block.

 Nick

 On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We have a custom RFNOC block that we have created. When we using
> GNURadio/Python everything works fine. When follow the examples in
> uhd/host/examples and generate an executable using C++, we get an error on
> execution.
>
> We noticed that on start up the python program has no issue locating
> controllers for all our custom blocks (FreqMod):
>
> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux;
> GNU C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
> 2019-Mar-27
> 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300 
> initialization
> sequence...
> 2019-Mar-27
> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
> size: 1472 bytes.
> 2019-Mar-27
> 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio 1x clock: 
> 200
> MHz
> 2019-Mar-27
> 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
> block control (NOC ID: 0xF1F0D000)
> 2019-Mar-27
> 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1302 MB/s)
> 2019-Mar-27
> 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1320 MB/s)
> 2019-Mar-27
> 

Re: [USRP-users] (no subject)

[John Medrano via USRP-users]

Hello,

We have verified that library is being linked.

When we run  nm  | grep 

We see the following:
00030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
0023d6e0 V _ZTIN3uhd5rfnoc19_block_ctrlE
00034b00 V _ZTSN3uhd5rfnoc19_ctrlE

We continue to get same error.

We have several blocks and we tried with all of them with same result.


On Wed, Mar 27, 2019 at 4:36 PM Nick Foster  wrote:

> Make very sure that your program is actually linking in the library
> correctly. Linkers are weird and their interaction with build systems is
> often unpredictable and sometimes perverse. Find the symbols in the
> compiled library with nm and see that they aren't undefined. Use make
> VERBOSE=1 to see the library actually being used.
>
> Nick
>
> On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
> wrote:
>
>> Thank you for the response.
>>
>> I have added to CMakeList.txt:
>>
>> find_library(SLADEW_LIB gnuradio-SLADEW)
>> if(NOT SLADEW_LIB)
>>   message(FATAL_ERROR "SLADEW library not found")
>> endif()
>>
>> add later I add:
>>
>> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES} ${Boost_LIBRARIES}
>> ${SLADEW_LIB})
>>
>> It compiles fine but I still get same messages on start up.
>>
>> Please advise:
>> John
>>
>>
>> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster  wrote:
>>
>>> Your program needs to be linked against the library which your custom
>>> block controller is compiled into, if in fact your block is using a custom
>>> block controller.
>>>
>>> uhd_usrp_probe and the other UHD utilities aren't linked against the
>>> custom library. This isn't generally a problem since the utilities and
>>> examples don't make use of your custom block.
>>>
>>> Nick
>>>
>>> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello,

 We have a custom RFNOC block that we have created. When we using
 GNURadio/Python everything works fine. When follow the examples in
 uhd/host/examples and generate an executable using C++, we get an error on
 execution.

 We noticed that on start up the python program has no issue locating
 controllers for all our custom blocks (FreqMod):

 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux; GNU
 C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
 2019-Mar-27
 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300 initialization
 sequence...
 2019-Mar-27
 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
 size: 1472 bytes.
 2019-Mar-27
 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio 1x clock: 200
 MHz
 2019-Mar-27
 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
 block control (NOC ID: 0xF1F0D000)
 2019-Mar-27
 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
 passed (Throughput: 1302 MB/s)
 2019-Mar-27
 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
 passed (Throughput: 1320 MB/s)
 2019-Mar-27
 13:52:51.430922,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
 block control (NOC ID: 0x12AD1001)
 2019-Mar-27
 13:52:51.529115,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
 block control (NOC ID: 0x12AD1001)
 2019-Mar-27
 13:52:51.628687,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
 block control (NOC ID: 0xD0C0)
 2019-Mar-27
 13:52:51.50,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
 block control (NOC ID: 0xD0C0)
 2019-Mar-27
 13:52:51.704298,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
 block control (NOC ID: 0xDDC0)
 2019-Mar-27
 13:52:51.741327,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
 block control (NOC ID: 0xDDC0)
 2019-Mar-27
 13:52:51.920546,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
 block control (NOC ID: 0x2833DDBAA1C8E99C)

 But when we run uhd_usrp_probe or our program we get:

 2019-Mar-27
 13:50:48.142811,0x7f489075e7c0,x300_impl.cpp:400,2,X300,X300 initialization
 sequence...
 2019-Mar-27
 13:50:48.424155,0x7f489075e7c0,x300_impl.cpp:1731,2,X300,Maximum frame
 size: 1472 bytes.
 2019-Mar-27
 13:50:48.494774,0x7f489075e7c0,x300_impl.cpp:942,2,X300,Radio 1x clock: 200
 MHz
 2019-Mar-27
 13:50:48.509901,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
 block control (NOC ID: 0xF1F0D000)
 2019-Mar-27
 13:50:48.546377,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
 passed (Throughput: 1317 MB/s)
 2019-Mar-27
 

Re: [USRP-users] (no subject)

[Nick Foster via USRP-users]

Make very sure that your program is actually linking in the library
correctly. Linkers are weird and their interaction with build systems is
often unpredictable and sometimes perverse. Find the symbols in the
compiled library with nm and see that they aren't undefined. Use make
VERBOSE=1 to see the library actually being used.

Nick

On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
wrote:

> Thank you for the response.
>
> I have added to CMakeList.txt:
>
> find_library(SLADEW_LIB gnuradio-SLADEW)
> if(NOT SLADEW_LIB)
>   message(FATAL_ERROR "SLADEW library not found")
> endif()
>
> add later I add:
>
> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES} ${Boost_LIBRARIES}
> ${SLADEW_LIB})
>
> It compiles fine but I still get same messages on start up.
>
> Please advise:
> John
>
>
> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster  wrote:
>
>> Your program needs to be linked against the library which your custom
>> block controller is compiled into, if in fact your block is using a custom
>> block controller.
>>
>> uhd_usrp_probe and the other UHD utilities aren't linked against the
>> custom library. This isn't generally a problem since the utilities and
>> examples don't make use of your custom block.
>>
>> Nick
>>
>> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> We have a custom RFNOC block that we have created. When we using
>>> GNURadio/Python everything works fine. When follow the examples in
>>> uhd/host/examples and generate an executable using C++, we get an error on
>>> execution.
>>>
>>> We noticed that on start up the python program has no issue locating
>>> controllers for all our custom blocks (FreqMod):
>>>
>>> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux; GNU
>>> C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
>>> 2019-Mar-27 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300
>>> initialization sequence...
>>> 2019-Mar-27
>>> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
>>> size: 1472 bytes.
>>> 2019-Mar-27
>>> 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio 1x clock: 200
>>> MHz
>>> 2019-Mar-27
>>> 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
>>> block control (NOC ID: 0xF1F0D000)
>>> 2019-Mar-27
>>> 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>> passed (Throughput: 1302 MB/s)
>>> 2019-Mar-27
>>> 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>> passed (Throughput: 1320 MB/s)
>>> 2019-Mar-27
>>> 13:52:51.430922,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
>>> block control (NOC ID: 0x12AD1001)
>>> 2019-Mar-27
>>> 13:52:51.529115,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
>>> block control (NOC ID: 0x12AD1001)
>>> 2019-Mar-27
>>> 13:52:51.628687,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
>>> block control (NOC ID: 0xD0C0)
>>> 2019-Mar-27
>>> 13:52:51.50,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
>>> block control (NOC ID: 0xD0C0)
>>> 2019-Mar-27
>>> 13:52:51.704298,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
>>> block control (NOC ID: 0xDDC0)
>>> 2019-Mar-27
>>> 13:52:51.741327,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
>>> block control (NOC ID: 0xDDC0)
>>> 2019-Mar-27
>>> 13:52:51.920546,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
>>> block control (NOC ID: 0x2833DDBAA1C8E99C)
>>>
>>> But when we run uhd_usrp_probe or our program we get:
>>>
>>> 2019-Mar-27 13:50:48.142811,0x7f489075e7c0,x300_impl.cpp:400,2,X300,X300
>>> initialization sequence...
>>> 2019-Mar-27
>>> 13:50:48.424155,0x7f489075e7c0,x300_impl.cpp:1731,2,X300,Maximum frame
>>> size: 1472 bytes.
>>> 2019-Mar-27
>>> 13:50:48.494774,0x7f489075e7c0,x300_impl.cpp:942,2,X300,Radio 1x clock: 200
>>> MHz
>>> 2019-Mar-27
>>> 13:50:48.509901,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
>>> block control (NOC ID: 0xF1F0D000)
>>> 2019-Mar-27
>>> 13:50:48.546377,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>> passed (Throughput: 1317 MB/s)
>>> 2019-Mar-27
>>> 13:50:48.596601,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>> passed (Throughput: 1304 MB/s)
>>> 2019-Mar-27
>>> 13:50:48.638428,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
>>> block control (NOC ID: 0x12AD1001)
>>> 2019-Mar-27
>>> 13:50:48.736751,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
>>> block control (NOC ID: 0x12AD1001)
>>> 2019-Mar-27
>>> 13:50:48.838951,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
>>> block control (NOC ID: 0xD0C0)
>>> 2019-Mar-27
>>> 13:50:48.877079,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
>>> block control (NOC ID: 

Re: [USRP-users] (no subject)

[John Medrano via USRP-users]

Thank you for the response.

I have added to CMakeList.txt:

find_library(SLADEW_LIB gnuradio-SLADEW)
if(NOT SLADEW_LIB)
  message(FATAL_ERROR "SLADEW library not found")
endif()

add later I add:

target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES} ${Boost_LIBRARIES}
${SLADEW_LIB})

It compiles fine but I still get same messages on start up.

Please advise:
John


On Wed, Mar 27, 2019 at 3:00 PM Nick Foster  wrote:

> Your program needs to be linked against the library which your custom
> block controller is compiled into, if in fact your block is using a custom
> block controller.
>
> uhd_usrp_probe and the other UHD utilities aren't linked against the
> custom library. This isn't generally a problem since the utilities and
> examples don't make use of your custom block.
>
> Nick
>
> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello,
>>
>> We have a custom RFNOC block that we have created. When we using
>> GNURadio/Python everything works fine. When follow the examples in
>> uhd/host/examples and generate an executable using C++, we get an error on
>> execution.
>>
>> We noticed that on start up the python program has no issue locating
>> controllers for all our custom blocks (FreqMod):
>>
>> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux; GNU
>> C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
>> 2019-Mar-27 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300
>> initialization sequence...
>> 2019-Mar-27
>> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
>> size: 1472 bytes.
>> 2019-Mar-27 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio
>> 1x clock: 200 MHz
>> 2019-Mar-27
>> 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
>> block control (NOC ID: 0xF1F0D000)
>> 2019-Mar-27
>> 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>> passed (Throughput: 1302 MB/s)
>> 2019-Mar-27
>> 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>> passed (Throughput: 1320 MB/s)
>> 2019-Mar-27
>> 13:52:51.430922,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
>> block control (NOC ID: 0x12AD1001)
>> 2019-Mar-27
>> 13:52:51.529115,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
>> block control (NOC ID: 0x12AD1001)
>> 2019-Mar-27
>> 13:52:51.628687,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
>> block control (NOC ID: 0xD0C0)
>> 2019-Mar-27
>> 13:52:51.50,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
>> block control (NOC ID: 0xD0C0)
>> 2019-Mar-27
>> 13:52:51.704298,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
>> block control (NOC ID: 0xDDC0)
>> 2019-Mar-27
>> 13:52:51.741327,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
>> block control (NOC ID: 0xDDC0)
>> 2019-Mar-27
>> 13:52:51.920546,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
>> block control (NOC ID: 0x2833DDBAA1C8E99C)
>>
>> But when we run uhd_usrp_probe or our program we get:
>>
>> 2019-Mar-27 13:50:48.142811,0x7f489075e7c0,x300_impl.cpp:400,2,X300,X300
>> initialization sequence...
>> 2019-Mar-27
>> 13:50:48.424155,0x7f489075e7c0,x300_impl.cpp:1731,2,X300,Maximum frame
>> size: 1472 bytes.
>> 2019-Mar-27 13:50:48.494774,0x7f489075e7c0,x300_impl.cpp:942,2,X300,Radio
>> 1x clock: 200 MHz
>> 2019-Mar-27
>> 13:50:48.509901,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
>> block control (NOC ID: 0xF1F0D000)
>> 2019-Mar-27
>> 13:50:48.546377,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>> passed (Throughput: 1317 MB/s)
>> 2019-Mar-27
>> 13:50:48.596601,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>> passed (Throughput: 1304 MB/s)
>> 2019-Mar-27
>> 13:50:48.638428,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
>> block control (NOC ID: 0x12AD1001)
>> 2019-Mar-27
>> 13:50:48.736751,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
>> block control (NOC ID: 0x12AD1001)
>> 2019-Mar-27
>> 13:50:48.838951,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
>> block control (NOC ID: 0xD0C0)
>> 2019-Mar-27
>> 13:50:48.877079,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
>> block control (NOC ID: 0xD0C0)
>> 2019-Mar-27
>> 13:50:48.916659,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
>> block control (NOC ID: 0xDDC0)
>> 2019-Mar-27
>> 13:50:48.957457,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
>> block control (NOC ID: 0xDDC0)
>> 2019-Mar-27
>> 13:50:49.135814,0x7f489075e7c0,block_ctrl_base_factory.cpp:77,3,RFNOC,Can't
>> find a block controller for key FreqMod, using default block
>>  controller!
>> 2019-Mar-27
>> 

Re: [USRP-users] (no subject)

[Nick Foster via USRP-users]

Your program needs to be linked against the library which your custom block
controller is compiled into, if in fact your block is using a custom block
controller.

uhd_usrp_probe and the other UHD utilities aren't linked against the custom
library. This isn't generally a problem since the utilities and examples
don't make use of your custom block.

Nick

On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We have a custom RFNOC block that we have created. When we using
> GNURadio/Python everything works fine. When follow the examples in
> uhd/host/examples and generate an executable using C++, we get an error on
> execution.
>
> We noticed that on start up the python program has no issue locating
> controllers for all our custom blocks (FreqMod):
>
> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux; GNU
> C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
> 2019-Mar-27 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300
> initialization sequence...
> 2019-Mar-27
> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
> size: 1472 bytes.
> 2019-Mar-27 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio
> 1x clock: 200 MHz
> 2019-Mar-27
> 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
> block control (NOC ID: 0xF1F0D000)
> 2019-Mar-27
> 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1302 MB/s)
> 2019-Mar-27
> 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1320 MB/s)
> 2019-Mar-27
> 13:52:51.430922,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
> block control (NOC ID: 0x12AD1001)
> 2019-Mar-27
> 13:52:51.529115,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
> block control (NOC ID: 0x12AD1001)
> 2019-Mar-27
> 13:52:51.628687,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
> block control (NOC ID: 0xD0C0)
> 2019-Mar-27
> 13:52:51.50,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
> block control (NOC ID: 0xD0C0)
> 2019-Mar-27
> 13:52:51.704298,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
> block control (NOC ID: 0xDDC0)
> 2019-Mar-27
> 13:52:51.741327,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
> block control (NOC ID: 0xDDC0)
> 2019-Mar-27
> 13:52:51.920546,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
> block control (NOC ID: 0x2833DDBAA1C8E99C)
>
> But when we run uhd_usrp_probe or our program we get:
>
> 2019-Mar-27 13:50:48.142811,0x7f489075e7c0,x300_impl.cpp:400,2,X300,X300
> initialization sequence...
> 2019-Mar-27
> 13:50:48.424155,0x7f489075e7c0,x300_impl.cpp:1731,2,X300,Maximum frame
> size: 1472 bytes.
> 2019-Mar-27 13:50:48.494774,0x7f489075e7c0,x300_impl.cpp:942,2,X300,Radio
> 1x clock: 200 MHz
> 2019-Mar-27
> 13:50:48.509901,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
> block control (NOC ID: 0xF1F0D000)
> 2019-Mar-27
> 13:50:48.546377,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1317 MB/s)
> 2019-Mar-27
> 13:50:48.596601,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1304 MB/s)
> 2019-Mar-27
> 13:50:48.638428,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
> block control (NOC ID: 0x12AD1001)
> 2019-Mar-27
> 13:50:48.736751,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
> block control (NOC ID: 0x12AD1001)
> 2019-Mar-27
> 13:50:48.838951,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
> block control (NOC ID: 0xD0C0)
> 2019-Mar-27
> 13:50:48.877079,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
> block control (NOC ID: 0xD0C0)
> 2019-Mar-27
> 13:50:48.916659,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
> block control (NOC ID: 0xDDC0)
> 2019-Mar-27
> 13:50:48.957457,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
> block control (NOC ID: 0xDDC0)
> 2019-Mar-27
> 13:50:49.135814,0x7f489075e7c0,block_ctrl_base_factory.cpp:77,3,RFNOC,Can't
> find a block controller for key FreqMod, using default block
>  controller!
> 2019-Mar-27
> 13:50:49.139122,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
> block control (NOC ID: 0x2833DDBAA1C8E99C)
>
> The error we receive is directly related to the above. Please advise.
>
> Thank you,
> John
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Kyeong Su Shin via USRP-users]

Hello Kazem:


Just follow the instructions in the error message:


 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
 "/usr/local/bin/uhd_image_loader" \
--args="type=usrp2,addr=192.168.10.3"


You may have to add "sudo" in front of the commands. Also, you may have to 
install python-request to get uhd_images_downloader.py working. Finally, you 
may have to power-cycle the USRP after running the above commands.


Regards,

Kyeong Su Shin


보낸 사람: kazem chm via USRP-users  대신 USRP-users 

보낸 날짜: 2018년 4월 28일 토요일 오후 11:14:04
받는 사람: usrp-users@lists.ettus.com
제목: [USRP-users] (no subject)


Good day dear Sir,
I am a new user of Ubuntu and USRP. I'm trying to connect my PC to USRP N200, 
but I have encountered the error below. I have installed  and uninstalled my 
GNU radio and UHD several times, but what I get is still the latest version in 
which is not compatible with my FPGA. I guess I need to upgrade my FPGA on USRP 
but I have no idea how to do that. Please give me a step by step guide to solve 
this problem.

warm regards,
Kazem

The error:
RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
 "/usr/local/bin/uhd_image_loader" \
--args="type=usrp2,addr=192.168.10.3"



Sent from Mail for Windows 10


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject)

[Derek Kozel via USRP-users]

Hello Kazem,

Did you get my previous message?
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056283.html

You are correct that you need to upgrade the USRP's FPGA image.

Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
 "/usr/local/bin/uhd_image_loader" \
--args="type=usrp2,addr=192.168.10.3"

Here is the manual page.
http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash

Regards,
Derek


On Sat, Apr 28, 2018 at 7:14 AM, kazem chm via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Good day dear Sir,
> I am a new user of Ubuntu and USRP. I'm trying to connect my PC to USRP
> N200, but I have encountered the error below. I have installed  and
> uninstalled my GNU radio and UHD several times, but what I get is still the
> latest version in which is not compatible with my FPGA. I guess I need to
> upgrade my FPGA on USRP but I have no idea how to do that. Please give me a
> step by step guide to solve this problem.
>
> warm regards,
> Kazem
>
> The error:
> RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>  "/usr/local/bin/uhd_image_loader" \
> --args="type=usrp2,addr=192.168.10.3"
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] (no subject) (Ron Economos)

[Marcus D. Leech via USRP-users]

You might consider "remoting" using something like an Odroid XU4, which
has a fair amount of compute capacity, and supports USB 3, and has a
1GiGe port. 

On 2017-07-19 13:14, Sirkin, Joshua F. via USRP-users wrote:

> Thanks for the suggestions, but unfortunately this solution won't work for 
> me.  I am trying to use this to have the B210 located quite a distance from 
> any computer.  I'd like to to be able to load the firmware over this link 
> too.  Recompiling the firmware to not use USB 2 looks like the most promising 
> path right now, I just still am not quite fully sure how to do that and if it 
> will work.
> 
> 
> From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of 
> usrp-users-requ...@lists.ettus.com [usrp-users-requ...@lists.ettus.com]
> Sent: Wednesday, July 19, 2017 12:00 PM
> To: usrp-users@lists.ettus.com
> Subject: EXTERNAL: USRP-users Digest, Vol 83, Issue 19
> 
> Send USRP-users mailing list submissions to
> usrp-users@lists.ettus.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> or, via email, send a message with subject or body 'help' to
> usrp-users-requ...@lists.ettus.com
> 
> You can reach the person managing the list at
> usrp-users-ow...@lists.ettus.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of USRP-users digest..."
> 
> Today's Topics:
> 
> 1. Re: Source code of the UHD examples (Martin Braun)
> 2. Ettus Research is Hiring! (Manuel Uhm)
> 3. ABI compatibility mismatch error
> (Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC])
> 4. Re: ABI compatibility mismatch error (Martin Braun)
> 5. Re: Trigger Signal (Martin Braun)
> 6. Re: (no subject) (Ron Economos)
> 7. Centos 6.5 with X310?? (Mark Koenig)
> 8. Re: Web server on E310 (Martin Braun)
> 9. Re: Centos 6.5 with X310?? (Martin Braun)
> 10. 3.9.7 Release Announcement (Derek Kozel)
> 11. Questions to run a loopback example on B200 (Jie Song)
> 12.  E310_sg3 FPGA Verilog code heirarchy
> (Estrada Lupianez, Jenniffer Marie)
> 13. Re: E310_sg3 FPGA Verilog code heirarchy (Martin Braun)
> 14. Re: Questions to run a loopback example on B200 (Marcus D. Leech)
> 15. Re: Centos 6.5 with X310?? (Marcus M?ller)
> 16. Re: Centos 6.5 with X310?? (Anon Lister)
> 17. Re: DDC's Filters in B210 (altu? kaya)
> 18. Re: DDC's Filters in B210 (Derek Kozel)
> 19. 3.10.2.0 Release Candidate 1 Announcement (Derek Kozel)
> 20. B210 for TDD (Jie Song)
> 
> ------------------
> 
> Message: 1
> Date: Tue, 18 Jul 2017 09:01:00 -0700
> From: Martin Braun <martin.br...@ettus.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] Source code of the UHD examples
> Message-ID: <174e6c01-a4a8-7ecd-a497-829470900...@ettus.com>
> Content-Type: text/plain; charset=windows-1252
> 
> On 07/18/2017 08:22 AM, Jie Song via USRP-users wrote: 
> 
>> Hi,
>> 
>> Are  there any source codes for those examples in the UHD software
>> library directory and I can refer to?
> 
> Jay,
> 
> https://github.com/EttusResearch/uhd/tree/maint/host/examples
> 
> -- M
> 
> --
> 
> Message: 2
> Date: Tue, 18 Jul 2017 09:01:50 -0700
> From: "Manuel Uhm" <manuel@ettus.com>
> To: <usrp-users@lists.ettus.com>
> Subject: [USRP-users] Ettus Research is Hiring!
> Message-ID: <046b01d2ffdf$2afa43c0$80eecb40$@ettus.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi everyone,
> 
> Ettus Research is currently looking for a USRP Product Manager. If you're a
> long time USRP user and always wanted to be able to drive the direction and
> feature set of next generation USRPs, this is your chance!
> 
> This is a full-time position with a strong preference to be located in our
> Santa Clara office with the rest of the team. Ettus will pay for relocation.
> The full job description can be found on our website here:
> 
> https://www.ettus.com/career/details/14
> 
> Cheers,
> 
> Manuel
> 
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170718/ab7a2af9/attachment-0001.html>
> 
> --
> 
> Message: 3
> Date: Tue, 18 Jul 2017 16:24:06 +
> From: "Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]"
> <konstantin.j.math...@nasa.gov>
> To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subje