Send USRP-users mailing list submissions to
        [email protected]

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
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. Re: USRP B210 Floating Wire Connections in the RTL Schematic
      (Jonathon Pendlum)
   2. Problems with the UHD and connection to B210 (Florian Lolies)
   3. Re: Problems with the UHD and connection to B210 (Marcus M?ller)
   4. ZMQ on E310 (???)
   5. Re: ZMQ on E310 (Nate Temple)
   6. synchronization between N210 and X310 (john liu)
   7. Synchronized tx/rx (ROBIN TORTORA)
   8. Re: USRP B210 Floating Wire Connections in the RTL Schematic
      (altu? kaya)
   9. Clock Period Definitions of B210 (altu? kaya)
  10. E310 autoboot (Perkins, Daniel A)
  11. Different streaming modes at the same time with same USRP
      hardware (Felipe Augusto Pereira de Figueiredo)


----------------------------------------------------------------------

Message: 1
Date: Mon, 26 Jun 2017 09:01:51 -0700
From: Jonathon Pendlum <[email protected]>
To: altu? kaya <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B210 Floating Wire Connections in the
        RTL Schematic
Message-ID:
        <cagdo0utvftlcq4rshrn-qkcwzcb_ynuqi4oagn9dpaa8u-7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Altug,

Have you tried tracing those nets in the Verilog source code?

Jonathon

On Mon, Jun 26, 2017 at 2:57 AM, altu? kaya via USRP-users <
[email protected]> wrote:

> Hello everyone,
>
> I synthesized and mapped the B210 FPGA code provided in
> https://github.com/EttusResearch/fpga. However, there are some unwired,
> floating wires in the RTL schematic, I attached a screen shot of it.
>
> Another abnormality in the RTL schematic is in b200_core module. Only two
> of the input wires are not connected and those are rx0 and rx1 (Screen shot
> is attached). Are not those are the main output of the ADC? If not, where
> is the main output of the ADC?
>
> Looking forward your answers,
> Altug Kaya
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170626/25cfdea1/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 26 Jun 2017 16:28:34 +0000 (UTC)
From: Florian Lolies <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Problems with the UHD and connection to B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

Hi,?i have a few problems with the installation of UHD and can't connect to my 
B210 USRP because of that. I'm working on it with openSUSE Leap 42.2 and I'm 
new in the field of SDR and Linux.?I tried to install UHD Version? 
003_010_001_001 according to the "Building and installing UHD from source 
code"-Guide at 
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux?The
 Problems starts with the "cmake"-command. I get the notification that the B200 
Board (including the B210?) and other stuff was disabled:??...?-- 
######################################################?
-- # UHD disabled components??????????????????????????? ??
-- ######################################################--?? * USB?--?? * GPSD?
--?? * B100?
--?? * B200?
--?? * E100?
--?? * E300?
--?? * USRP1?
--?? * Manual?
--?? * API/Doxygen?...??After that and the command "make", the test of the 
make-build with "make test" was full of errors as 
well:??...?linux-dvxz:/home/Florian/workarea-uhd/uhd/host/build # make test?
Running tests...?
Test project /home/Florian/workarea-uhd/uhd/host/build?
????? Start? 1: addr_test?
?1/32 Test? #1: addr_test ........................***Failed??? 0.06 sec?
????? Start? 2: buffer_test?
?2/32 Test? #2: buffer_test ......................***Failed??? 0.03 sec?
????? Start? 3: byteswap_test?
?3/32 Test? #3: byteswap_test ....................***Failed??? 0.03 sec?
????? Start? 4: cast_test?
?4/32 Test? #4: cast_test ........................***Failed??? 0.07 sec?
????? Start? 5: chdr_test?
?5/32 Test? #5: chdr_test ........................***Failed??? 0.07 sec?
????? Start? 6: convert_test?
?6/32 Test? #6: convert_test .....................***Failed??? 0.19 sec?
????? Start? 7: dict_test?
?7/32 Test? #7: dict_test ........................***Failed??? 0.07 sec?
????? Start? 8: error_test?
?8/32 Test? #8: error_test .......................***Failed??? 0.08 sec?
...??I was searching for a solution on the Ettus Research website and Google as 
well, but I can't find a solution that fits to my problem. I checked or 
installed the repositories GCC, GCC-C++, Clang, LibUSB, Mako, Doxygen, ? but 
none of them helps and I don't have a successful installation. 
I can't connect to the USRP ("uhd_find_devices" or "uhd_usrp_probe") but the 
USB connection works, i can identify the USRP (lsusb).
?Can anybody help me with that problem???Thanks in advance and best 
regards?Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170626/081a748a/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 26 Jun 2017 18:38:41 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problems with the UHD and connection to B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"

Hi Florian,

the build system doesn't seem to be able to satisfy the dependencies of
the USB-connected USRP drivers. So: You're probably missing
libusb(x)-devel, or whatever it's called on openSUSE. The text further
up in the CMake output should be more explicit about what's missing :)

Best regards,
Marcus


On 26.06.2017 18:28, Florian Lolies via USRP-users wrote:
> Hi, 
> ihave a few problems with the installation of UHD and can't connect to
> my B210 USRP because of that. I'm working on it with openSUSE Leap
> 42.2 and I'm new in the field of SDR and Linux. 
> I tried to install UHD Version  003_010_001_001 according to the
> "Building and installing UHD from source code"-Guide at
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>
>  
> The Problems starts with the "cmake"-command. I get the notification
> that the B200 Board (including the B210?) and other stuff was disabled: 
>  
> ... 
> -- ###################################################### 
> -- # UHD disabled components                              
> -- ######################################################
> --   * USB 
> --   * GPSD 
> --   * B100 
> --   * B200 
> --   * E100 
> --   * E300 
> --   * USRP1 
> --   * Manual 
> --   * API/Doxygen 
> ... 
>  
> After that and the command "make", the test of the make-build with
> "make test" was full of errors as well: 
>  
> ... 
> linux-dvxz:/home/Florian/workarea-uhd/uhd/host/build # make test 
> Running tests... 
> Test project /home/Florian/workarea-uhd/uhd/host/build 
>       Start  1: addr_test 
>  1/32 Test  #1: addr_test ........................***Failed    0.06 sec 
>       Start  2: buffer_test 
>  2/32 Test  #2: buffer_test ......................***Failed    0.03 sec 
>       Start  3: byteswap_test 
>  3/32 Test  #3: byteswap_test ....................***Failed    0.03 sec 
>       Start  4: cast_test 
>  4/32 Test  #4: cast_test ........................***Failed    0.07 sec 
>       Start  5: chdr_test 
>  5/32 Test  #5: chdr_test ........................***Failed    0.07 sec 
>       Start  6: convert_test 
>  6/32 Test  #6: convert_test .....................***Failed    0.19 sec 
>       Start  7: dict_test 
>  7/32 Test  #7: dict_test ........................***Failed    0.07 sec 
>       Start  8: error_test 
>  8/32 Test  #8: error_test .......................***Failed    0.08 sec 
> ... 
>  
> I was searching for a solution on the Ettus Research website and
> Google aswell, but I can't find a solution that fits to my problem. I
> checked or installed the repositories GCC, GCC-C++, Clang, LibUSB,
> Mako, Doxygen, ? but none of them helps and I don't have a successful
> installation.
> I can't connect to the USRP ("uhd_find_devices" or "uhd_usrp_probe")
> but the USB connection works, i can identify the USRP (lsusb).
>  
> Can anybody help me with that problem? 
>  
> Thanks in advance and best regards 
> Florian
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170626/8149921c/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 27 Jun 2017 15:34:26 +0900
From: ??? <[email protected]>
To: [email protected]  <[email protected]>
Subject: [USRP-users] ZMQ on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

Hi all

 

I&#39;m testing ZMQ streaming with GRC and E310
It was succesful local loopback test with ZMQ_src and ZMQ_sink on
development computer
But when I python zmq_srcpy on E310 USRP , I got error
It&#39;s not easy for me to understand what this message mean

 

 

Traceback (most recent call last):
 File &quot;gmq_srcpy&quot;, line 66, in &lt;module&gt;
 main()
 File &quot;gmq_srcpy&quot;, line 55, in main
 tb = top_block_cls()
 File &quot;gmq_srcpy&quot;, line 32, in __init__
 selfzeromq_pub_sink_0 = zeromqpub_sink(grsizeof_gr_complex, 1,
&quot;tcp://127001:60&quot;, 100, True, -1)
 File
&quot;/usr/lib/python27/site-packages/gnuradio/zeromq/zeromq_swigpy&quot;,
line 105, in make
 return _zeromq_swigpub_sink_make(*args, **kwargs)
TypeError: pub_sink_make() takes at most 5 arguments (6 given)

 

 

Regards
Kim taeyeong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/81b9644d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zmq_src.png
Type: image/png
Size: 26662 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/81b9644d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zmq_sink.png
Type: image/png
Size: 16641 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/81b9644d/attachment-0003.png>

------------------------------

Message: 5
Date: Tue, 27 Jun 2017 00:37:24 -0700
From: Nate Temple <[email protected]>
To: ??? <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ZMQ on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

Hi Kim,

In the generated Python file "gmq_src.py", you need to edit the line:

self.zeromq_pub_sink_0 = zeromq.pub_sink(gr.sizeof_gr_complex, 1, 
"tcp://127.0.0.1:60", 100, True, -1)

to be:

self.zeromq_pub_sink_0 = zeromq.pub_sink(gr.sizeof_gr_complex, 1, 
"tcp://127.0.0.1:60", 100, True)

Note the removal of the last parameter ", -1".

This is due to mismatch of GNU Radio version between your host where you 
generated the Python file and the version running on the E3xx.

The Application Note linked below covers using the ZMQ sinks with the E3xx to 
stream processed audio from the E3xx to the host and might be useful for 
reference and uses the XMLRPC blocks to adjust freq/gain/etc.

https://kb.ettus.com/Streaming_processed_data_from_the_E31x_with_GNU_Radio_and_ZMQ

Regards,
Nate


> On Jun 26, 2017, at 11:34 PM, ??? via USRP-users <[email protected]> 
> wrote:
> 
> Hi all
>  
> I'm testing ZMQ streaming with GRC and E310.
> It was succesful local loopback test with ZMQ_src and ZMQ_sink on development 
> computer.
> But when I python zmq_src.py on E310 USRP , I got error.
> It's not easy for me to understand what this message mean.
>  
>  
> Traceback (most recent call last):
>   File "gmq_src.py", line 66, in <module>
>     main()
>   File "gmq_src.py", line 55, in main
>     tb = top_block_cls()
>   File "gmq_src.py", line 32, in __init__
>     self.zeromq_pub_sink_0 = zeromq.pub_sink(gr.sizeof_gr_complex, 1, 
> "tcp://127.0.0.1:60", 100, True, -1)
>   File "/usr/lib/python2.7/site-packages/gnuradio/zeromq/zeromq_swig.py", 
> line 105, in make
>     return _zeromq_swig.pub_sink_make(*args, **kwargs)
> TypeError: pub_sink_make() takes at most 5 arguments (6 given)
>  
>  
> Regards
> Kim taeyeong
> <zmq_src.png><zmq_sink.png>_______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




------------------------------

Message: 6
Date: Tue, 27 Jun 2017 17:31:57 +0800
From: john liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] synchronization between N210 and X310
Message-ID:
        <CAF6NnTJwu3NZW=X5zqMysjwJSyCwOh0zsKpTH4mxb=rdyyc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,all,
Could we achieve  synchronization between N210 and X310 with gpsdo(or
octoclock)? If yes,
MIMO will be OK?

best regards
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/ee3342af/attachment-0001.html>

------------------------------

Message: 7
Date: Tue, 27 Jun 2017 08:29:59 -0400 (EDT)
From: ROBIN TORTORA <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Synchronized tx/rx
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

Windows 7, UHD 3.9.2, X310 with UBX daughtercard.


I have an app that does time syncd tx/rx on the same daughtercard.


When I schedule a timed transmit, what does the time spec actually represent?


    Is it the time that samples start through the Tx chain?


Similarly on the recv side, what does the time spec actually represent?


    Is it the time samples start coming through the Rx chain?


Here is my issue:  I have "calibrated" out the delay of the loopback by sending 
a test pulse through tx chain starting the tx at time T1 while simultaneously 
starting the Rx chain at T1 also.  Lets call the measured delay 10 samples, i 
simply remove 10 samples form the beginning of the rx data and continue on 
merrily.


80% of the time, everything is completely syncd perfectly for the length of the 
Tx/Rx.


20% of the time, the rx is off by 1 sample, so the delay is actually 11 samples 
rather than 10.  Everything is syncd, just off by 1 sample.


This is executed with the same freq and sample rate.


Is there anything organically "wrong" with my approach?


Is there anything I can do differently to eliminate the 20% of the time 1 
sample mismatch?


It seems I am straddling some time bin and wondering if a different approach 
would more stable and looking for any suggestions...


Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/02daf8ac/attachment-0001.html>

------------------------------

Message: 8
Date: Tue, 27 Jun 2017 15:04:34 +0200
From: altu? kaya <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B210 Floating Wire Connections in the
        RTL Schematic
Message-ID:
        <CAHq6UV8=cjb6nb2znxl44ylw0fqzu4nambsvqq9+eop0nbq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear Jonathon Pendlum,

Thank you for your advice. I traced the top module in order to check if
there is a floating wire or not and I realized that there is no floating or
unconnected wire. The problem stems from the RTL schematic. RTL is not a
reliable way to observe module connections. I switched to Technology
Schematic by choosing keep_hierarchy as soft in order to observe at least
some modules. Then, I select b200_io and b200_core and realized that
outputs of b200_io, namely rx_i0 and rx_q0, are connected to the input of
the b200_core, namely rx_0.

Thank you,
Altug

On Mon, Jun 26, 2017 at 6:01 PM, Jonathon Pendlum <
[email protected]> wrote:

> Hi Altug,
>
> Have you tried tracing those nets in the Verilog source code?
>
> Jonathon
>
> On Mon, Jun 26, 2017 at 2:57 AM, altu? kaya via USRP-users <
> [email protected]> wrote:
>
>> Hello everyone,
>>
>> I synthesized and mapped the B210 FPGA code provided in
>> https://github.com/EttusResearch/fpga. However, there are some unwired,
>> floating wires in the RTL schematic, I attached a screen shot of it.
>>
>> Another abnormality in the RTL schematic is in b200_core module. Only two
>> of the input wires are not connected and those are rx0 and rx1 (Screen shot
>> is attached). Are not those are the main output of the ADC? If not, where
>> is the main output of the ADC?
>>
>> Looking forward your answers,
>> Altug Kaya
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/97eae78c/attachment-0001.html>

------------------------------

Message: 9
Date: Tue, 27 Jun 2017 15:10:20 +0200
From: altu? kaya <[email protected]>
To: [email protected]
Subject: [USRP-users] Clock Period Definitions of B210
Message-ID:
        <CAHq6UV-iG58i3Mi4AXm1Mr==g0td2h2bvsjgu6x1lhmt9xx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello everyone,

I would like to simulate B210 and created a test bench for that. However, I
do not know the exact values of  cat_sclk_period, fx3_sclk_period,
pll_sclk_period, debug_clk_period, IFCLK_period. Is there a way to find
these values? Thank you.

I am looking forward to your reply,
Altug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/ab49361e/attachment-0001.html>

------------------------------

Message: 10
Date: Tue, 27 Jun 2017 14:05:07 +0000
From: "Perkins, Daniel A" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 autoboot
Message-ID:
        
<1e774efcea54114f863f197c525ba09a52f14...@wp-mbx1b.milky-way.battelle.org>
        
Content-Type: text/plain; charset="us-ascii"

I need to configure my E310 to boot automatically when power is applied.  The 
FAQ in the E310 manual references setting an autoboot parameter by adjusting:

/sys/devices/axi_pmu.3/autoboot

My SD Card image does not contain a axi_pmu.3 folder or an autoboot file 
anywhere in the file system that I am able to find.  My image is an earlier 
image from 2015.  The version-image file references "gnuradio-dev-image" with a 
timestamp of 201507211757.

Scanning through what appears to be firmware source code for the power 
supervisor microcontroller located here:
https://github.com/EttusResearch/uhd/tree/master/firmware/e300/battery
it looks like sending the right SPI command to the power supervisor chip from 
the FPGA might do the job assuming this code matches the factory E310 firmware.


  *   Does this code match the E310 factory code?
  *   How does this SPI command get sent?
  *   Will autoboot require any change to the power supervisor microcontroller 
code?


Daniel Perkins
Senior Research Scientist
Mission and Defense Technologies/Tactical Equipment
Office: 614.424.7687 | Mobile: 614.327.5535|
[email protected]<mailto:[email protected]>

Battelle
505 King Aveune
Columbus, OH  43102
http://www.battelle.org<http://www.battelle.org/>

Connect with Battelle
Facebook<http://www.facebook.com/battelle> | 
LinkedIn<http://www.linkedin.com/company/battelle>
Twitter<http://www.twitter.com/Battelle> | 
YouTube<http://www.youtube.com/user/battelleinnovations>

This message is intended only for the use of the individual or entity to which 
it is addressed, and may contain information that is privileged, confidential 
and/or otherwise exempt from disclosure under applicable law. If the reader of 
this message is not the intended recipient or the employee or agent responsible 
for delivering the message to the intended recipient, any disclosure, 
dissemination, distribution, copying or other use of this communication or its 
substance is prohibited. If you have received this communication in error, 
please return to the sender and delete from your computer system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/10551baf/attachment-0001.html>

------------------------------

Message: 11
Date: Tue, 27 Jun 2017 16:28:57 +0200
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Different streaming modes at the same time with
        same USRP hardware
Message-ID:
        <ca+abmw+jrfjf19918_-h4yibp8xlrhx6bert+gcezqc_ylg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear folks,

I've got a x310 and I'd like to know if it is possible to open two streams
with different streaming modes at the same time in the same USRP hardware.

For example, the first RF chain would be configures as

*UHD_STREAM_MODE_START_CONTINUOUS*

and the second one would be set to

*UHD_STREAM_MODE_NUM_SAMPS_AND_DONE*

Is is possible?

Thanks and Kind regards,

Felipe Augusto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/56430d28/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


------------------------------

End of USRP-users Digest, Vol 82, Issue 26
******************************************

Reply via email to