[USRP-users] timeout error

2019-04-17 Thread Koyel Das (Vehere) via USRP-users
Hi,


For receiving data using usrp,  sweeping a frequency range, following the code 
rx_multisamples.cpp, I am setting the frequency then doing START_CONTINUOUS; 
after receiving I am doing STOP_CONTINUOUS. After the code runs for sometime I 
am getting ERROR_CODE_TIMEOUT and the application stops. The we have to restart 
usrp to rerun the application. Please suggest solution.


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


[USRP-users] RFNOC Replay Block

2019-04-17 Thread John Medrano via USRP-users
Hello,

We are attempting to run replay_samples_from_file example.

We run:

replay_samples_from_from_file --freq 1e9 --file ../test.dat

The program hangs:
Connecting 0/Replay_0 ==> 0/Radio_0
Using streamer args: block_id=0/Replay_0,block_port=0
Replay file size: 65536 bytes (8192 qwords, 16384 samples)
Record base address:  0x0
Record buffer size:   65536 bytes
Record fullness:  0
Play base address:0x0
Play buffer size: 65536 bytes
Restarting record buffer...
Sending data to be recorded...

We are simply running the example, please advise on how we can get this
working.

Thanks
___
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)

2019-04-17 Thread 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 t

Re: [USRP-users] how to properly use static libuhd?

2019-04-17 Thread Nick Foster via USRP-users
I suspect the same solution I gave a couple weeks ago will work here:

set(MY_LIB_OPT -Wl,--whole-archive libuhd -Wl,--no-whole-archive)
target_link_libraries(myapp ${MY_LIB_OPT} <...the rest of your libs...>)

On Wed, Apr 17, 2019 at 3:02 AM Paolo Palana via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi to all the mailing list.
>
> I've a question about the correct way to use a static version of libuhd
> (namely libuhd.a)
>
> For experimental reason I need a way to build an executable of mine that
> "embed" a specific version of libuhd. I enabled (throutg
> -DENABLE_STATIC_LIBS=ON) the compilation of the static library and I get
> the libuhd.a file.
>
> After that I modified my CMakeLists.txt to link against libuhd.a. The
> compilation and link process goes smooth. So far so good.
>
> The problem arise when I execute the program. No radio (x310 in my case)
> is found. I traced the problem.
>
> The shared version of libuhd (libuhd.so) has a init function (that
> should be register_x300_device, defined in x300_impl.cpp). that is
> called before main  This function is no longer called when I compile
> using libuhd.a, may be because there is no the dynamic loader involved.
>
> The question is. Can I call it from my code? And if yes how? I tried
> different ways, but no success.
>
> Thank you for your attention.
>
> My version is 003-010-003-000.
>
> Paolo
>
>
>
> ___
> 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] Unable to set the thread priority

2019-04-17 Thread Marcus D. Leech via USRP-users

On 04/17/2019 09:10 AM, Fabian Schwartau via USRP-users wrote:

Hi everyone,

for some reasons I suddenly see the error message, that UHD cannot set 
the thread priority. It has been working before.

As you can see below my settings seem to be correct:

fschwa@rfserv:~$ tail -n 3 /etc/security/limits.conf
@plugdev- rtprio99

# End of file
fschwa@rfserv:~$ groups
fschwa adm tty dialout cdrom sudo dip plugdev lpadmin sambashare alfa
fschwa@rfserv:~$

The message disappears when running the application as root. What 
could be the cause?

The USRPs are connected using 10G Ethernet, UHD version is 3.10.2.

Best regards,
Fabian


Have you done a system upgrade?

Have you changed /etc/security/limits.confrecently, and is there 
perhaps a syntax error in it?


If you reboot, does the behavior change?



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


[USRP-users] Unable to set the thread priority

2019-04-17 Thread Fabian Schwartau via USRP-users

Hi everyone,

for some reasons I suddenly see the error message, that UHD cannot set 
the thread priority. It has been working before.

As you can see below my settings seem to be correct:

fschwa@rfserv:~$ tail -n 3 /etc/security/limits.conf
@plugdev- rtprio99

# End of file
fschwa@rfserv:~$ groups
fschwa adm tty dialout cdrom sudo dip plugdev lpadmin sambashare alfa
fschwa@rfserv:~$

The message disappears when running the application as root. What could 
be the cause?

The USRPs are connected using 10G Ethernet, UHD version is 3.10.2.

Best regards,
Fabian

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


Re: [USRP-users] Problems with USRP X300 + PCI-Express Desktop Kit + Ubuntu 18.04

2019-04-17 Thread Piotr Krysik via USRP-users
Hi Nicola,

I just had exactly the same issue with UHD 3.14.0.0-72. Upgrading to
full 3.14 release of UHD (top of UHD-3.14 branch) solved the issue for me.

Best Regards,
Piotr Krysik

W dniu 04.02.2019 o 14:42, Michailow, Nicola via USRP-users pisze:
>
> Hi,
>
>  
>
> I am trying to connect a USRP X300 (1x UBX) to a PC using the
> PCI-Express Desktop Kit and I would like to ask for some help trying
> to make sense of the errors described below.
>
>  
>
...
> sdr@sdr-fujitsu-pc:~$ sudo /usr/local/lib/uhd/examples/benchmark_rate
> --rx_rate=100e6 --args resource=RIO0
>
>  
>
>   [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.14.0.0-85-g33233e5c
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [00:00:00.11] Creating the usrp device with: resource=RIO0...
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [X300] X300 initialization sequence...
>
>   [INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [X300] Using LVBITX bitfile
> /usr/local/share/uhd/images/usrp_x300_fpga_XG.lvbitx...
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [X300] Radio 1x clock: 200 MHz
>
>   [INFO] [GPS] No GPSDO found
>
>   [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
>
>   [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1313 MB/s)
>
>   [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1315 MB/s)
>
>   [INFO] [0/Radio_0] Initializing block control (NOC ID:
> 0x12AD1001)
>
>   [INFO] [0/Radio_1] Initializing block control (NOC ID:
> 0x12AD1001)
>
>   [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
>
>   [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
>
>   [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
>
>   [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>
>   [ERROR] [UHD] Exception caught in safe-call.
>
>     in max287x::~max287x() [with max287x_regs_t =
> max2871_regs_t]
>
>     at
> /home/sdr/nicola/uhd/host/lib/include/uhdlib/usrp/common/max287x.hpp:475
>
>   shutdown(); -> EnvironmentError: IOError: Block ctrl (CE_01_Port_40)
> packet parse error - EnvironmentError: IOError: Expected packet index:
> 1016 Received index: 1080
>
>  
>
...

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


[USRP-users] how to properly use static libuhd?

2019-04-17 Thread Paolo Palana via USRP-users
Hi to all the mailing list.

I've a question about the correct way to use a static version of libuhd
(namely libuhd.a)

For experimental reason I need a way to build an executable of mine that
"embed" a specific version of libuhd. I enabled (throutg
-DENABLE_STATIC_LIBS=ON) the compilation of the static library and I get
the libuhd.a file.

After that I modified my CMakeLists.txt to link against libuhd.a. The
compilation and link process goes smooth. So far so good.

The problem arise when I execute the program. No radio (x310 in my case)
is found. I traced the problem.

The shared version of libuhd (libuhd.so) has a init function (that
should be register_x300_device, defined in x300_impl.cpp). that is
called before main  This function is no longer called when I compile
using libuhd.a, may be because there is no the dynamic loader involved.

The question is. Can I call it from my code? And if yes how? I tried
different ways, but no success.

Thank you for your attention.

My version is 003-010-003-000.

Paolo



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


Re: [USRP-users] vita_time in noc_shell and axi_wrapper

2019-04-17 Thread Jonathon Pendlum via USRP-users
Hi,

The vita_time input should be ignored. It is meant to be used with the
Radio Core. For timed commands, you should instead compare the vita time
from the header of incoming CHDR packets with the "set_time" signal of the
settings bus. You can see an example of this with the DDC / DUC blocks,
where the module axi_tag_time is used to tag samples to trigger commands at
a specific vita time.

Jonathon

On Wed, Apr 10, 2019 at 8:49 AM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>  What is the difference for vita_time between the vita_time in noc_shell
> and axi_wrapper in a RFNOC module?
> I noticed that there is vita_time input for noc_shell, but also a
> vita_time can be included in the axi_wrapper input s_axis_data_tuser. I
> guess that for noc_shell, the vita_time input is for the universal
> synchronization time between modules. And the vita_time in the axi_wrapper
> input s_axis_data_tuser is for schedule a future command. For example, I
> can add a delay time for transmission in the header in s_axis_data_tuser in
> siggen rfnoc example.
> ___
> 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