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. OFDM Synch not producing output (Manik Singhal)
2. Re: Ethernet over SFP+ in custom FPGA design (X3x0)
(Sugandha Gupta)
3. Re: GNU Radio/USRP Image Issues (Taylor Eisman)
4. List of SDRs that are able to work in burst mode like USRP
(Paul I.)
5. Re: GNU Radio/USRP Image Issues (Derek Kozel)
6. GPSDO RS-232 cable (Mann, John - 0662 - MITLL)
7. No UHD Device error (Jalal Shams)
8. Re: No UHD Device error (Jalal Shams)
9. Re: Question on proper use of recv (Long, Jeffrey P.)
10. Re: No UHD Device error (Neel Pandeya)
11. Re: Question on proper use of recv (Derek Kozel)
12. Re: GPSDO RS-232 cable (Martin Braun)
13. Re: List of SDRs that are able to work in burst mode like
USRP (Martin Braun)
14. Re: List of SDRs that are able to work in burst mode like
USRP (Kevin Hung)
15. Re: B205i transient behavior (Marcus D. Leech)
16. more power e3xx device (carry chen)
17. Re: B205i transient behavior (Dominik Eyerly)
18. about FPGA x310 (john liu)
19. Re: No UHD Device error (Jalal Shams)
20. Re: Generating custom FSBL for E310 (EJ Kreinar)
21. disabling LO correction on E310 and B205mini-i (Francois Quitin)
22. Re: disabling LO correction on E310 and B205mini-i
(Steven Knudsen)
23. Re: B205i transient behavior (Marcus D. Leech)
24. Re: disabling LO correction on E310 and B205mini-i (EJ Kreinar)
----------------------------------------------------------------------
Message: 1
Date: Wed, 5 Apr 2017 14:15:59 -0400
From: Manik Singhal <[email protected]>
To: [email protected]
Subject: [USRP-users] OFDM Synch not producing output
Message-ID:
<CAG86GbPsXNnXf=emdwsm464p1x9jw81pgbgnvkteyy9mcqq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am trying to replicate the OFDM receiver from the FPGA demonstration
presentation, and I have hit a bit of roadstop. The OFDM synch block is not
producing output, which results in timeout errors.
My flow graph: RFNOC Radio --> RFNOC: FIFO --> RFNOC: OFDM Synch --> RFNOC:
FFT --> GNUradio: Vector to Stream --> GNU Radio: Qt GUI Sink.
I have not yet incorporated the equaliser or the constellation demapper.
But even with just the synchroniser the flow graph does not work, but if I
remove it from the above flow graph I can see some data on the frequency
plot.
I am using the schmidl cox block defined in rfnoc-ofdm branch.
Any suggestions to help solve the problem or fixes would be greatly
appreciated.
Best regards,
Manik Singhal
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/7731a21c/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 5 Apr 2017 13:22:24 -0700
From: Sugandha Gupta <[email protected]>
To: Christian Lenz <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Ethernet over SFP+ in custom FPGA design
(X3x0)
Message-ID:
<cag_kd145w0kb4v1qt8erc5h6g5qdqyqnqz381xwn4arfsmo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Christian
It would be good if you could explain your application and need to have a
custom image. From your questions, it looks like you would be redoing a lot
of the infrastructure already present in the X3x0. In your application, if
you want to add new blocks to the existing code to offload SW tasks, you
can use the existing RFNoC framework
<https://kb.ettus.com/Getting_Started_with_RFNoC_Development>.
See inline for the answers.
Let me know if you have any further questions.
Cheers
Sugandha
On Tue, Apr 4, 2017 at 6:54 AM, Christian Lenz via USRP-users <
[email protected]> wrote:
> Hi,
>
> I?m currently evaluating the effort/feasibility of running a custom FPGA
> image in a USRP X3x0. One thing left is the connection Host PC <?> FPGA
> to exchange control/status information (neither high throughput nor low
> latency needed here).
> To achieve this, I have the idea of using the provided IP to interface one
> of the SFP+ ports on the FPGA side and connect to a host PC using the SFP 1
> Gigabit Ethernet Interface Kit.
> Related to this are the following questions:
>
> 1. I traced down the signals, beginning from the SFP+ FPGA pins. The main
> ethernet functionality (PHY+MAC) is included in the ?x300_sfpp_io_core?,
> correct?
>
>> Yes.
> Additionally, do I need to incorporate also the ?eth_interface? included
> in ?x300_core/bus_int?, which somehow translates the AXI data streams
> coming from the ?x300_sfpp_io_core??
>
>> The eth_interface has 2 parts
- eth_dispatch - It routes the incoming packets appropriately based on
the MAC, IP, chdr (or not?), etc.
- chdr_eth_framer - It re-constructs the chdr packets coming back
from the crossbar -> adds the MAC and IP.
So, I guess you would need it.
>
> 2. I want to use the ?x300_sfpp_io_core? for a single SFP+ port with
> protocol ?1GbE?. I did found all the required source files except for the
> modules ?one_gig_eth_pcs_pma_support?, located in the ?one_gige_phy? and
> the ?axi64_8k_2clk_fifo?, located in the ?simple_gemac_wrapper?. There are
> only some references in related makefiles but I can not find the verilog
> source files where the modules are described in. Am I misleaded at some
> point?
>
>> These files are generated during the build process.
Look in :
<fpga-repo>/usrp3/top/x300/build-ip/<part-number>/one_gig_eth_pcs_pma_example/one_gig_eth_pcs_pma_example.srcs/sources_1/imports/example_design/support/*
> 3. This question may also apply to the plain UHD FPGA design: Let?s assume
> I get the SFP+ core running within my custom FPGA design. How do I
> communicate with the FPGA using an ethernet-connected host PC?
>
>> That is what you have a existing UHD code for.
Since the provided cores included in ?x300_sfpp_io_core? implement PHY +
> MAC functionalities, do I need additional cores to implement IP and TCP/UDP
> or in which way do you transfer data between Host and FPGA using Ethernet
> (see also my question 1.)? The target would be to establish a packet based
> communication over Ethernet and having AXI streams for sending/receiving on
> the FPGA side.
>
>> If it is a chdr packet, then the current FPGA design handles it.
>
> Hopefully, my questions are not too far away from the oridnary USRP use
> case.
>
> Thanks for the help,
> Christian
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Sugandha Gupta
Staff Software Engineer
Ettus Research
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/b5ab6514/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 5 Apr 2017 13:46:13 -0500
From: Taylor Eisman <[email protected]>
To: Muhammad Munir <[email protected]>
Cc: Derek Kozel <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] GNU Radio/USRP Image Issues
Message-ID:
<capr5ws3jnizukvyosvssksyfqdokcjxektw9nzjbt8so-oq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks, guys! It turns out Muhammad was correct. The IP address in GNU
Radio needed to be "addr=192.168.1.3".
For completeness, the reason the IP address is 192.168.10.3 and not
192.168.10.2 is because of a switch that controls multiple USRPs.
Also, the tag identification is:
003.010.001.001-release
Thu Jan 26 23:45:53 PST 2017
I do not have Linux commands, but I was curious to try the bash shell to
see the functionality available. I'll continue to see if it is possible to
do anything with the USRP through this bash shell. It correctly picked up
the USRP connection. GRC won't work, for sure, but I'll keep this e-mail in
mind when I'm trying to interface using the bash shell.
On Wed, Apr 5, 2017 at 12:34 AM, Muhammad Munir <[email protected]>
wrote:
> Hi Taylor,
> Referring to the errors shown in picture,
> >>UHD Error:
> Device discovery error: unknown key format:
> 192.168.10.3
> I encountered this error in Gnuradio when I entered the device address in
> a wrong format. The correct format is "addr=192.168.10.3"
>
> >>RuntimeError: LookupError: KeyError: No device found for ------>
> Device Address:
> 192.168.10.3:
> There are a few reasons for this error.
> i. Your device is not connected to the PC.
> ii. You are using different gateway for ethernet
> connection. The IP address of your PC must be of 192.168.*10*.xx and
> gateway of type 192.168.10.1
> I did not worked using MATLAB.
>
>
>
>
>
>
> On Wed, Apr 5, 2017 at 3:56 AM, Derek Kozel via USRP-users <
> [email protected]> wrote:
>
>> Hello Taylor,
>>
>> Thanks for posting here, it helps get the question in front of lots of
>> USRP users who use Windows, GNU Radio, MATLAB, and LabView.
>>
>> Your images do not show the top line of the GNU Radio output which will
>> include a line similar to this one which would tell us the version of UHD
>> which your GNU Radio install is using.
>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_4.0.0.rfnoc-devel-283-g7ff43262
>>
>> You should check, just to be sure, the tag file which is downloaded in
>> the same directory as all the images from uhd_images_downloader. It will
>> contain a pair of lines similar to these. The UHD versions should
>> approximately match depending on how you installed UHD and GNU Radio.
>> 4.0.0.rfnoc-devel-238-g39a41476
>> Wed Mar 1 18:00:58 CST 2017
>>
>> The NI USRP-2920 is the same hardware as the Ettus branded N210 with a
>> WBX daughterboard. You can use the usrp_image_loader utility from the
>> command line in Windows to load the usrp_n210_r_fpga.bin and
>> usrp_n210_fw.bin files on. The NI-USRP updated will probably also work but
>> I do not have it currently installed to try.
>>
>> ./uhd_image_loader --args="type=usrp2"
>> --fpga=~/src/uhd/images/images/usrp_n210_r4_fpga.bin
>> --fw=~/src/uhd/images/images/usrp_n210_fw.bin
>>
>> The image will not be used until after you power cycle the USRP.
>>
>> You can run uhd_usrp_probe to find out information about what is
>> currently loaded.
>>
>> ./uhd_usrp_probe --args="type=usrp2,addr=192.168.10.3"
>>
>> _____________________________________________________
>> /
>> | Device: USRP2 / N-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: N210r4
>> | | hardware: 2577
>> | | product: 30194
>> | | mac-addr: a0:36:fa:35:30:1f
>> | | ip-addr: 192.168.1.50
>> | | subnet: 255.255.255.0
>> | | gateway: 192.168.1.1
>> | | gpsdo: none
>> | | serial: E1R10ZFNW
>> | | FW Version: 12.4
>> | | FPGA Version: 11.1
>> ...
>>
>>
>> Installing the new image may cause MATLAB to be unable to find the USRP.
>> This is because the binary GNU Radio installer for Windows and the MATLAB
>> environment use separate UHD versions.
>>
>> Regards,
>> Derek
>>
>> On Tue, Apr 4, 2017 at 3:24 PM, Taylor Eisman via USRP-users <
>> [email protected]> wrote:
>>
>>> Two programs, MATLAB and GNU Radio, are giving me different results when
>>> searching for the USRP on my network.
>>> My setup is Laptop -> Wired Ethernet -> Switch -> NI USRP-2920.
>>>
>>> MATLAB can detect the USRP device, while GNU Radio throws an error
>>> whenever it tries to identify the USRP device at 192.168.10.3.
>>>
>>> My computer is configured with the static IP address 192.168.10.1. I'm
>>> using Windows 10 for this setup. I recently downloaded the automated
>>> NI-USRP driver software. Apparently, this software updates the USRP
>>> image to the latest firmware. Installing new firmware onto the USRP had no
>>> effect on the error message.
>>>
>>>
>>> I ran the "uhd_image_downloadeder" and it gave me tons of different
>>> images. I'm assuming I'd want to install the N21x_fw and N21x_fpga files.
>>> Are there better ones suited for the USRP-2920?
>>>
>>>
>>> And finally, I couldn't find the program that allows me to see the
>>> images already installed, but due to the last update of the firmware being
>>> yesterday, I'm fairly confident these images are the ones installed
>>> currently.
>>>
>>>
>>> I'm concerned that the image status is reading a null value currently.
>>> However, it still reads in MATLAB just fine.
>>>
>>>
>>> Which images should I install from that repository seen in the second
>>> picture?
>>>
>>>
>>> Thanks,
>>>
>>> Taylor
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>> _______________________________________________
>> 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/20170405/79565c48/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 5 Apr 2017 23:43:53 +0300
From: "Paul I." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] List of SDRs that are able to work in burst mode
like USRP
Message-ID:
<caj8gl+hyfi0oa1ij09dajmoggr8rofjizspbsggbfr3cuuf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
Does anybody know which other SDRs are able to work in burst mode like
USRP? I.e. to receive/transmit burst of data at specific time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/fbd66157/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 5 Apr 2017 13:52:19 -0700
From: Derek Kozel <[email protected]>
To: Taylor Eisman <[email protected]>
Cc: Muhammad Munir <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] GNU Radio/USRP Image Issues
Message-ID:
<CAA+K=tsXNpXQ3DqzFGF1NQrFqTxYMonXOeSM06aSX6L42D8=f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Taylor,
I'm glad that you found the issue.
This is the Bash on Windows shell? I know that at least one person has
tried UHD on that with at least some success, but no one has tested it in
depth. Please do share if you try that in depth, it would be very
interesting.
The commands I described are all available from the default Windows console
as well. They are installed by the GNU Radio binary installer but not
included in the PATH variable so you would need to call them from the
install folder.
Regards,
Derek
On Wed, Apr 5, 2017 at 11:46 AM, Taylor Eisman <[email protected]>
wrote:
> Thanks, guys! It turns out Muhammad was correct. The IP address in GNU
> Radio needed to be "addr=192.168.1.3".
>
> For completeness, the reason the IP address is 192.168.10.3 and not
> 192.168.10.2 is because of a switch that controls multiple USRPs.
> Also, the tag identification is:
> 003.010.001.001-release
> Thu Jan 26 23:45:53 PST 2017
>
> I do not have Linux commands, but I was curious to try the bash shell to
> see the functionality available. I'll continue to see if it is possible to
> do anything with the USRP through this bash shell. It correctly picked up
> the USRP connection. GRC won't work, for sure, but I'll keep this e-mail in
> mind when I'm trying to interface using the bash shell.
>
>
> On Wed, Apr 5, 2017 at 12:34 AM, Muhammad Munir <[email protected]>
> wrote:
>
>> Hi Taylor,
>> Referring to the errors shown in picture,
>> >>UHD Error:
>> Device discovery error: unknown key format:
>> 192.168.10.3
>> I encountered this error in Gnuradio when I entered the device address in
>> a wrong format. The correct format is "addr=192.168.10.3"
>>
>> >>RuntimeError: LookupError: KeyError: No device found for ------>
>> Device Address:
>> 192.168.10.3:
>> There are a few reasons for this error.
>> i. Your device is not connected to the PC.
>> ii. You are using different gateway for ethernet
>> connection. The IP address of your PC must be of 192.168.*10*.xx and
>> gateway of type 192.168.10.1
>> I did not worked using MATLAB.
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 5, 2017 at 3:56 AM, Derek Kozel via USRP-users <
>> [email protected]> wrote:
>>
>>> Hello Taylor,
>>>
>>> Thanks for posting here, it helps get the question in front of lots of
>>> USRP users who use Windows, GNU Radio, MATLAB, and LabView.
>>>
>>> Your images do not show the top line of the GNU Radio output which will
>>> include a line similar to this one which would tell us the version of UHD
>>> which your GNU Radio install is using.
>>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_4.0.0.rfnoc-devel-283-g7ff43262
>>>
>>> You should check, just to be sure, the tag file which is downloaded in
>>> the same directory as all the images from uhd_images_downloader. It will
>>> contain a pair of lines similar to these. The UHD versions should
>>> approximately match depending on how you installed UHD and GNU Radio.
>>> 4.0.0.rfnoc-devel-238-g39a41476
>>> Wed Mar 1 18:00:58 CST 2017
>>>
>>> The NI USRP-2920 is the same hardware as the Ettus branded N210 with a
>>> WBX daughterboard. You can use the usrp_image_loader utility from the
>>> command line in Windows to load the usrp_n210_r_fpga.bin and
>>> usrp_n210_fw.bin files on. The NI-USRP updated will probably also work but
>>> I do not have it currently installed to try.
>>>
>>> ./uhd_image_loader --args="type=usrp2"
>>> --fpga=~/src/uhd/images/images/usrp_n210_r4_fpga.bin
>>> --fw=~/src/uhd/images/images/usrp_n210_fw.bin
>>>
>>> The image will not be used until after you power cycle the USRP.
>>>
>>> You can run uhd_usrp_probe to find out information about what is
>>> currently loaded.
>>>
>>> ./uhd_usrp_probe --args="type=usrp2,addr=192.168.10.3"
>>>
>>> _____________________________________________________
>>> /
>>> | Device: USRP2 / N-Series Device
>>> | _____________________________________________________
>>> | /
>>> | | Mboard: N210r4
>>> | | hardware: 2577
>>> | | product: 30194
>>> | | mac-addr: a0:36:fa:35:30:1f
>>> | | ip-addr: 192.168.1.50
>>> | | subnet: 255.255.255.0
>>> | | gateway: 192.168.1.1
>>> | | gpsdo: none
>>> | | serial: E1R10ZFNW
>>> | | FW Version: 12.4
>>> | | FPGA Version: 11.1
>>> ...
>>>
>>>
>>> Installing the new image may cause MATLAB to be unable to find the USRP.
>>> This is because the binary GNU Radio installer for Windows and the MATLAB
>>> environment use separate UHD versions.
>>>
>>> Regards,
>>> Derek
>>>
>>> On Tue, Apr 4, 2017 at 3:24 PM, Taylor Eisman via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Two programs, MATLAB and GNU Radio, are giving me different results
>>>> when searching for the USRP on my network.
>>>> My setup is Laptop -> Wired Ethernet -> Switch -> NI USRP-2920.
>>>>
>>>> MATLAB can detect the USRP device, while GNU Radio throws an error
>>>> whenever it tries to identify the USRP device at 192.168.10.3.
>>>>
>>>> My computer is configured with the static IP address 192.168.10.1. I'm
>>>> using Windows 10 for this setup. I recently downloaded the automated
>>>> NI-USRP driver software. Apparently, this software updates the USRP
>>>> image to the latest firmware. Installing new firmware onto the USRP had no
>>>> effect on the error message.
>>>>
>>>>
>>>> I ran the "uhd_image_downloadeder" and it gave me tons of different
>>>> images. I'm assuming I'd want to install the N21x_fw and N21x_fpga files.
>>>> Are there better ones suited for the USRP-2920?
>>>>
>>>>
>>>> And finally, I couldn't find the program that allows me to see the
>>>> images already installed, but due to the last update of the firmware being
>>>> yesterday, I'm fairly confident these images are the ones installed
>>>> currently.
>>>>
>>>>
>>>> I'm concerned that the image status is reading a null value currently.
>>>> However, it still reads in MATLAB just fine.
>>>>
>>>>
>>>> Which images should I install from that repository seen in the second
>>>> picture?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Taylor
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20170405/59ce3cb0/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 5 Apr 2017 21:20:34 +0000
From: "Mann, John - 0662 - MITLL" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] GPSDO RS-232 cable
Message-ID:
<d51b499176a305408baf4a778770d5c035a76...@lle2k10-mbx01.mitll.ad.local>
Content-Type: text/plain; charset="us-ascii"
I just replaced an ancient N200 with a brand new one. I'd like to move the
GPSDO card from the old unit to the new one. The old N200 used a longer
RS-232 cable (22 cm vs. 8 cm). Is there any way to use the old cable with
the new N200, or do I need to find an 8 cm one?
John Mann
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/130e5d34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5457 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/130e5d34/attachment-0001.p7s>
------------------------------
Message: 7
Date: Thu, 6 Apr 2017 03:04:05 +0500
From: Jalal Shams <[email protected]>
To: [email protected]
Subject: [USRP-users] No UHD Device error
Message-ID:
<camnwuytqla18hjwrew-ewhxen7vpfulrzr2zvjnlfkwratu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am working on implementing OpenBts on Gnuradio. In doing so I am getting
the same error as shown in the picture. This picture is of Ubuntu 12.04 as
I was following "Getting started with Openbts" but I got the same error
when I was using Ubuntu 14.04.
I am using USRP 2 device of ettus research and I am wondering what is it
that I am doing wrong ? One thing is that I am not getting the ethernet
lights and when I ping to the default IP of USRP i-e 192.168.10.2 I get
"DESTINATION HOST UNREACHABLE" (though I have tried various cables and
also provided static host IP)
[image: Inline image 1]
I will be thankful to you guys
Jalal
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/9a281547/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 77107 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/9a281547/attachment-0001.png>
------------------------------
Message: 8
Date: Thu, 6 Apr 2017 03:05:55 +0500
From: Jalal Shams <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] No UHD Device error
Message-ID:
<camnwuytxsmxnq5je7hbom1gwkmbjuevqg5sus5apbdfvurt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
In addition I am using Virtual box
On Thu, Apr 6, 2017 at 3:04 AM, Jalal Shams <[email protected]> wrote:
> Hi all,
> I am working on implementing OpenBts on Gnuradio. In doing so I am getting
> the same error as shown in the picture. This picture is of Ubuntu 12.04 as
> I was following "Getting started with Openbts" but I got the same error
> when I was using Ubuntu 14.04.
> I am using USRP 2 device of ettus research and I am wondering what is it
> that I am doing wrong ? One thing is that I am not getting the ethernet
> lights and when I ping to the default IP of USRP i-e 192.168.10.2 I get
> "DESTINATION HOST UNREACHABLE" (though I have tried various cables and
> also provided static host IP)
> [image: Inline image 1]
>
> I will be thankful to you guys
> Jalal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/dab266ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 77107 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/dab266ee/attachment-0001.png>
------------------------------
Message: 9
Date: Wed, 5 Apr 2017 22:36:31 +0000
From: "Long, Jeffrey P." <[email protected]>
To: Paolo Palana <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Question on proper use of recv
Message-ID:
<dm5pr09mb13724d3c5ccc1f8d4c397a26d9...@dm5pr09mb1372.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Paolo-
Thanks you. Yes I want to stream from two at the same time. I did finally look
into the multi sample example and I think I follow this. I also learned that
you do need to set a time to start streaming with multichannel otherwise there
is a sync issue even if you don't necessarily care about that.
What I ended up doing was (and I am not sure if it works yet but it seems to
compile and run) something similar to the multi channel too but I did not want
to do that copy after the recv but rather move the pointers along to different
part of the vectors on each grab. There are other Ettus examples where they do
this and it seems more efficient so my thinking is that what I have below would
be how to do it for multichannel. Perhaps somebody can chime in if they think
it makes sense.
Thanks
Jeff
#define PKTS 10 //This is how many multiples of the max num samps you want to
get
samps_per_buff = _rxStreamer->get_max_num_samps();
size_t total_num_samps = (PKTS * samps_per_buff);
size_t num_acc_samps = 0; //Init this
//allocate buffers to receive with samples (one buffer per channel)
int chans = _usrp->get_rx_num_channels();
std::vector<std::vector<std::complex<float> > > buffs(chans,
std::vector<std::complex<float> >(samps_per_buff));
//create a vector of pointers to point to each of the channel buffers
static std::vector<std::complex<float> *> buff_ptrs(chans);
for (size_t i = 0; i < chans; i++)
buff_ptrs[i]= &buffs[i].front();
while (num_acc_samps < total_num_samps) {
size_t num_rx_samps = _rxStreamer->recv(buff_ptrs,
samps_per_buff, _md_rx, timeout, true);
num_acc_samps += num_rx_samps;
if (num_acc_samps < total_num_samps)
for (size_t i = 0; i < chans; i++)
buff_ptrs[i] =
&buffs[i].at(num_acc_samps);//Move the pointers along
}
From: USRP-users [mailto:[email protected]] On Behalf Of Paolo
Palana via USRP-users
Sent: Wednesday, April 05, 2017 3:30 AM
To: [email protected]
Subject: Re: [USRP-users] Question on proper use of recv
On 04/05/2017 01:50 AM, Long, Jeffrey P. via USRP-users wrote:
Derek-
Thanks. Sounds like multiple chunks is more reliable. My challenge is trying to
figure out how to do this for multichannel streaming.
I suppose you are thinking about reading, at the same time, from two
daughterboards.
The vector of pointers to vectors is a little confusing for me and I am not
sure how to dereference properly to append each grab to the larger buffer.
In order to understand how to this, I read the rx_multi_samples.cpp example
provided with lbuhd sources. What I do when I need to a multichannel reading is:
1) std::vector<std::vector<std::complex<short> >
>buffs(usrp->get_rx_num_channels(), std::vector<std::complex<short> >(spb));
Allocating a vector of vectors that olds the two buffer where recv will put
the samples coming from the radio.
2) std::vector<std::complex<short> *> buff_ptrs;
allocate a vector of ponters.
and then
for (size_t i = 0; i < buffs.size(); i++)
buff_ptrs.push_back(&buffs[i].front());
namely store the pointer at the beginning of each buffer.
3) read samples
while(tot_rx_samples < tot_samples)
{
size_t num_rx_samps = rx_stream->recv(buff_ptrs, spb, md, timeout);
//cout<<"Num sampes read = "<<num_rx_samps<<endl;
for (uint32_t i = 0; i < num_rx_samps; i++) {
bufch1[2*i+0] = buffs[0].at(i).real();
-------------> samples coming from channel 0
bufch1[2*i+1] = buffs[0].at(i).imag();
bufch2[2*i+0] = buffs[1].at(i).real();
-------------> samples coming from channel 1
bufch2[2*i+1] = buffs[1].at(i).imag();
}
tot_rx_samples += num_rx_samps;
}
May be this is not the best way to perform multichannel read, but it works.
Hope this is interesting for you.
Have a good day.
Paolo
Jeff
From: Derek Kozel [mailto:[email protected]]
Sent: Tuesday, April 04, 2017 3:18 PM
To: Long, Jeffrey P.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Question on proper use of recv
Hello Jeff,
If you require an exact number of samples it is better to call recv in a loop
until all samples are received or an error is thrown. You can make the one
larger request with the total number of samples, but it is possible for recv to
return fewer samples in a few edge cases. If the call returns the full number
of samples in a single call the while loop introduces negligible overhead.
Regards,
Derek
On Tue, Apr 4, 2017 at 11:53 AM, Long, Jeffrey P. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
I am trying to better understand the use of :
virtual size_t uhd::rx_streamer::recv ( const buffs_type &
buffs,
const size_t nsamps_per_buff,
rx_metadata_t & metadata,
const double timeout = 0.1,
const bool one_packet = false
)
With respect to the fragmentation and whether to do multiple calls to this in a
loop as some of the Ettus examples with a single packet length do or one larger
request a multiple of packet lengths which I believe you can do with one_packet
set to false.
Thanks
Jeff
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170405/26148c42/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 5 Apr 2017 15:53:04 -0700
From: Neel Pandeya <[email protected]>
To: Jalal Shams <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] No UHD Device error
Message-ID:
<cacaxmv_scomcd2amq62uqzqnt7a_jgulldjxgeqf780_h3c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Jalal:
Several comments....
I would not recommend using a VM. First get things working on-the-metal.
The VM will limit throughput, and will require some configuration settings
for USB and Ethernet connections.
>From your screenshot, you're using UHD 3.8.0, which is quite old. I would
recommend using UHD 3.9.6.
You said you're using Ubuntu 12.04, which is also quite old. Again, I would
recommend using something newer, Ubuntu 16.04 ideally.
But the most important thing is to ask why you want to port OpenBTS to GNU
Radio? I cannot think of any reason to do this, and GNU Radio is not
well-suited for implementing applications such as cellular stacks (i.e.,
OpenBTS). There is a reason why none of the cellular stacks use GNU Radio.
--?Neel Pandeya
On 5 April 2017 at 15:05, Jalal Shams via USRP-users <
[email protected]> wrote:
> In addition I am using Virtual box
>
> On Thu, Apr 6, 2017 at 3:04 AM, Jalal Shams <[email protected]>
> wrote:
>
>> Hi all,
>> I am working on implementing OpenBts on Gnuradio. In doing so I am
>> getting the same error as shown in the picture. This picture is of Ubuntu
>> 12.04 as I was following "Getting started with Openbts" but I got the same
>> error when I was using Ubuntu 14.04.
>> I am using USRP 2 device of ettus research and I am wondering what is it
>> that I am doing wrong ? One thing is that I am not getting the ethernet
>> lights and when I ping to the default IP of USRP i-e 192.168.10.2 I get
>> "DESTINATION HOST UNREACHABLE" (though I have tried various cables and
>> also provided static host IP)
>> [image: Inline image 1]
>>
>> I will be thankful to you guys
>> Jalal
>>
>
>
> _______________________________________________
> 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/20170405/77da9d5d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 77107 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/77da9d5d/attachment-0001.png>
------------------------------
Message: 11
Date: Wed, 5 Apr 2017 16:43:30 -0700
From: Derek Kozel <[email protected]>
To: "Long, Jeffrey P." <[email protected]>
Cc: Paolo Palana <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Question on proper use of recv
Message-ID:
<CAA+K=tuc7LYUgFNwPt+rx0pDV944C5z6OMXqOHPxHRjyA=8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Jeff,
Your approach seems entirely reasonable.
Although it does not do multiple channels of acquisition the TwinRX example
is worth looking at as an example of receiving without copies. It takes the
same approach as you are describing, just with a single buffer.
https://github.com/EttusResearch/uhd/blob/379f922dabee3d8684a98a64787e9f0ba46caa68/host/examples/twinrx_freq_hopping.cpp#L84
Regards,
Derek
On Wed, Apr 5, 2017 at 3:36 PM, Long, Jeffrey P. via USRP-users <
[email protected]> wrote:
> Paolo-
>
>
>
> Thanks you. Yes I want to stream from two at the same time. I did finally
> look into the multi sample example and I think I follow this. I also
> learned that you do need to set a time to start streaming with multichannel
> otherwise there is a sync issue even if you don?t necessarily care about
> that.
>
>
>
> What I ended up doing was (and I am not sure if it works yet but it seems
> to compile and run) something similar to the multi channel too but I did
> not want to do that copy after the recv but rather move the pointers along
> to different part of the vectors on each grab. There are other Ettus
> examples where they do this and it seems more efficient so my thinking is
> that what I have below would be how to do it for multichannel. Perhaps
> somebody can chime in if they think it makes sense.
>
>
>
> Thanks
>
> Jeff
>
>
>
>
>
>
>
> #define PKTS 10 //This is how many multiples of the max num samps you
> want to get
>
>
>
> samps_per_buff = _rxStreamer->get_max_num_samps();
>
> size_t total_num_samps = (PKTS * samps_per_buff);
>
> size_t num_acc_samps = 0; //Init this
>
>
>
> //allocate buffers to receive with samples (one buffer per channel)
>
> int chans = _usrp->get_rx_num_channels();
>
> std::vector<std::vector<std::complex<float> > > buffs(chans,
> std::vector<std::complex<float> >(samps_per_buff));
>
> //create a vector of pointers to point to each of the channel buffers
>
> static std::vector<std::complex<float> *> buff_ptrs(chans);
>
> for (size_t i = 0; i < chans; i++)
>
> buff_ptrs[i]= &buffs[i].front();
>
>
>
>
>
> while (num_acc_samps < total_num_samps) {
>
>
>
> size_t num_rx_samps = _rxStreamer->recv(buff_ptrs,
> samps_per_buff, _md_rx, timeout, true);
>
> num_acc_samps += num_rx_samps;
>
> if (num_acc_samps < total_num_samps)
>
> for (size_t i = 0; i < chans; i++)
>
> buff_ptrs[i] =
> &buffs[i].at(num_acc_samps);//Move the pointers along
>
>
>
> }
>
>
>
>
>
>
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Paolo Palana via USRP-users
> *Sent:* Wednesday, April 05, 2017 3:30 AM
> *To:* [email protected]
>
> *Subject:* Re: [USRP-users] Question on proper use of recv
>
>
>
> On 04/05/2017 01:50 AM, Long, Jeffrey P. via USRP-users wrote:
>
> Derek-
>
>
>
> Thanks. Sounds like multiple chunks is more reliable. My challenge is
> trying to figure out how to do this for multichannel streaming.
>
> I suppose you are thinking about reading, at the same time, from two
> daughterboards.
>
>
> The vector of pointers to vectors is a little confusing for me and I am
> not sure how to dereference properly to append each grab to the larger
> buffer.
>
>
> In order to understand how to this, I read the rx_multi_samples.cpp
> example provided with lbuhd sources. What I do when I need to a
> multichannel reading is:
>
> 1) std::vector<std::vector<std::complex<short> >
> >buffs(usrp->get_rx_num_channels(),
> std::vector<std::complex<short> >(spb));
> Allocating a vector of vectors that olds the two buffer where recv
> will put the samples coming from the radio.
>
> 2) std::vector<std::complex<short> *> buff_ptrs;
> allocate a vector of ponters.
>
> and then
>
> for (size_t i = 0; i < buffs.size(); i++)
> buff_ptrs.push_back(&buffs[i].front());
>
> namely store the pointer at the beginning of each buffer.
>
> 3) read samples
>
> while(tot_rx_samples < tot_samples)
> {
> size_t num_rx_samps = rx_stream->recv(buff_ptrs, spb, md,
> timeout);
>
> //cout<<"Num sampes read = "<<num_rx_samps<<endl;
>
> for (uint32_t i = 0; i < num_rx_samps; i++) {
> bufch1[2*i+0] = buffs[0].at(i).real();
> -------------> samples coming from channel 0
> bufch1[2*i+1] = buffs[0].at(i).imag();
> bufch2[2*i+0] = buffs[1].at(i).real();
> -------------> samples coming from channel 1
> bufch2[2*i+1] = buffs[1].at(i).imag();
> }
> tot_rx_samples += num_rx_samps;
> }
>
>
> May be this is not the best way to perform multichannel read, but it works.
>
> Hope this is interesting for you.
>
> Have a good day.
>
> Paolo
>
>
>
>
> Jeff
>
>
>
> *From:* Derek Kozel [mailto:[email protected] <[email protected]>]
>
> *Sent:* Tuesday, April 04, 2017 3:18 PM
> *To:* Long, Jeffrey P.
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Question on proper use of recv
>
>
>
> Hello Jeff,
>
> If you require an exact number of samples it is better to call recv in a
> loop until all samples are received or an error is thrown. You can make the
> one larger request with the total number of samples, but it is possible for
> recv to return fewer samples in a few edge cases. If the call returns the
> full number of samples in a single call the while loop introduces
> negligible overhead.
>
> Regards,
>
> Derek
>
>
>
> On Tue, Apr 4, 2017 at 11:53 AM, Long, Jeffrey P. via USRP-users <
> [email protected]> wrote:
>
> I am trying to better understand the use of :
>
>
>
> virtual size_t uhd::rx_streamer::recv ( const buffs_type
> & buffs,
>
> const size_t nsamps_per_buff,
>
> rx_metadata_t & metadata,
>
> const double timeout = 0.1,
>
> const bool one_packet = false
>
> )
>
>
>
>
>
> With respect to the fragmentation and whether to do multiple calls to this
> in a loop as some of the Ettus examples with a single packet length do or
> one larger request a multiple of packet lengths which I believe you can do
> with one_packet set to false.
>
>
>
> Thanks
>
> Jeff
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20170405/59c061a0/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 5 Apr 2017 17:46:01 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO RS-232 cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
You should be good -- if the longer cable really doesn't work, you'll
get errors related to the GPS subsystem. Until then, keep using your
longer cable.
-- M
On 04/05/2017 02:20 PM, Mann, John - 0662 - MITLL via USRP-users wrote:
> I just replaced an ancient N200 with a brand new one. I?d like to move
> the GPSDO card from the old unit to the new one. The old N200 used a
> longer RS-232 cable (22 cm vs. 8 cm). Is there any way to use the old
> cable with the new N200, or do I need to find an 8 cm one?
>
>
>
> John Mann
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Wed, 5 Apr 2017 17:47:38 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] List of SDRs that are able to work in burst
mode like USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Paul,
please understand that many people on this specific list won't be giving
you info specifically about non-Ettus products. Feel free to ask this on
discuss-gnuradio.
Regards,
Martin
On 04/05/2017 01:43 PM, Paul I. via USRP-users wrote:
> Hello,
>
> Does anybody know which other SDRs are able to work in burst mode like
> USRP? I.e. to receive/transmit burst of data at specific time.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Wed, 5 Apr 2017 21:01:37 -0400
From: Kevin Hung <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] List of SDRs that are able to work in burst
mode like USRP
Message-ID:
<CAKU1+bgEdRQysX0xn_-9cAJ16wWQ_5=mmq+ju3h2ekbc45x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Maybe take a look at Pluto from Analog Devices.
On Wed, Apr 5, 2017 at 8:47 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> Paul,
>
> please understand that many people on this specific list won't be giving
> you info specifically about non-Ettus products. Feel free to ask this on
> discuss-gnuradio.
>
> Regards,
> Martin
>
> On 04/05/2017 01:43 PM, Paul I. via USRP-users wrote:
> > Hello,
> >
> > Does anybody know which other SDRs are able to work in burst mode like
> > USRP? I.e. to receive/transmit burst of data at specific time.
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> 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/20170405/97c0d861/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 05 Apr 2017 22:10:20 -0400
From: "Marcus D. Leech" <[email protected]>
To: Dominik Eyerly <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B205i transient behavior
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/05/2017 10:18 AM, Dominik Eyerly wrote:
>
> Hello,
>
> UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
> UHD_3.11.0.git-release, compiled for ARM
> B205 running on USB3.
>
> Doesn't matter if the port is terminated or if it has a signal, recv
> returns hard 0s, (not 1e-10 or the like) when a tx streamer is
> created. I've uploaded a simple bit of code that illustrates the
> behavior quite clearly.
>
> https://pastebin.com/ZAccunUe
>
> Please note that this code assumes you have 20dB of attenuation
> between rx and tx. However you can adjust the gain values
> appropriately if you do not.
>
> I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
> -lboost_system -luhd
>
> But honestly, this issue is not my primary concern. My primary concern
> is the ramp behavior. Note that the code I posted also illustrates the
> ramping behavior. For this it needs to be in loopback with 20dB
> attenuation (or more). I included a little helper function which
> performs a quick dump to a python file. If you have matplotlib for
> python you can uncomment the "dump_to_py" line in the rx thread and
> then simply run the generated file with python to see a quick plot of
> the iq data.
>
> What else could I do to further troubleshoot this?
>
> cheers,
> Dominik
>
There is an example program, called txrx_loopback_to_file that does
something similar to your test.
I wonder if it would be possible to do your tests with that, and see if
there is any change in behavior.
Also, what sample rates are you using?
>
> On 04/05/2017 02:25 PM, Marcus D. Leech wrote:
>> On 04/05/2017 05:57 AM, Dominik Eyerly wrote:
>>>
>>> Hello,
>>>
>>> Thanks for the reply. I should add I am doing this test at 3.8G.
>>>
>>> Response to (A)
>>>
>>> Are you saying that regardless of my tx gain setting, I need 40dB of
>>> attenuation? I believe at max tx gain the board outputs around
>>> 10-15dBm @3.8G. I currently have a 6dB pad on tx port, cabled to a
>>> splitter which is cabled to the rx port with an inline 10dB pad. The
>>> other splitter port is going directly into my VSA. Also, my tx gain
>>> is around 50dB. My understanding was that the max input power of the
>>> rx port is -15dBm. With this configuration I should be well under
>>> that, as shown on my VSA capture (~-35dBm).
>>>
>>> Response to (B)
>>>
>>> According to the rough specifications posted here:
>>> https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>>
>>> The IIP3 is -15dBm. As you can see on my VSA capture, it received
>>> -35dBm and that doesn't even include the extra 10dB pad on the ettus
>>> rx port. I should be good on linearity, should I not? The reason the
>>> power capture looks so wavy is probably because I have the LO's
>>> tuned to the same spot. When I move tx off by 100kHz the capture
>>> looks "nicer" but the ramp up behavior is still there. Also, on the
>>> link I posted above, the max input power is called out as 0 dBm...
>>> is that correct?
>>>
>>> Could you provide some input on the questions I brought up in my
>>> previous email? Namely:
>>>
>>> (1) recv returning 0s when a tx_streamer is created while receiving
>>> continuously.
>>>
>> Could you try a simple experiment here? Place a terminator on the
>> input to the RX side, and see if you get 0s in the recv buffer. I
>> want to distinguish
>> between an analog situation and a digital one.
>>
>>> (2) The ramp up behavior that is only present when transmitting
>>> during an active acquisition.
>>>
>> That's odd. What version of UHD are you using?
>>
>>
>>> I also want to mention that the first burst of power in my captures
>>> coincides with changing the frequency of the tx LO. This triggers an
>>> internal calibration of the AD chip which in turn outputs this brief
>>> burst. So at least this mystery is solved. I am curious, however, is
>>> it possible to allow the chip to perform its cal without actually
>>> seeing this signal at the tx port?
>>>
>> I'm not certain of exactly how it performs its calibration, but
>> likely there will always be some leakage when it is doing so.
>>
>>
>>> cheers,
>>> Dominik
>>>
>>>
>>> On 04/04/2017 04:54 PM, [email protected] wrote:
>>>>
>>>> How are you doing the physical loop-back? If directly-cabled,
>>>> you'll need about 40dB of attenuation in-line, to keep the receiver
>>>> from:
>>>>
>>>> (A) Being damaged
>>>>
>>>> (B) Remaining linear
>>>>
>>>> On 2017-04-04 09:14, Dominik Eyerly via USRP-users wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> My questions concern the B205i. I've uploaded some pictures to
>>>>> simplify the explaining process.
>>>>>
>>>>> http://imgur.com/a/XMAv6
>>>>>
>>>>> Basically, I want to transmit and receive a FSK waveform on one
>>>>> board (loopback). This means I've tuned both LOs to the same
>>>>> frequency. I've also inserted a splitter to be able to look at the
>>>>> signal on my VSA. This has allowed me to identify several problems.
>>>>>
>>>>> Let's start on the left:
>>>>> (B205i Receive - no zeros)
>>>>> Here you see the received power drop from the noise floor to
>>>>> -infinity because the rx_streamer was returning 0's. I've tracked
>>>>> this problem to the creation of a tx_streamer while an acquisition
>>>>> is running. This seems completely unacceptable; that calling a
>>>>> command on a chain (tx) that has nothing to do with rx, has an
>>>>> effect on rx. I could understand that the sample rate performance
>>>>> of rx is affected because they share a communication link, but not
>>>>> to actually alter the data that is returned by the recv call. Is
>>>>> this a known bug? Is there a workaround other than "don't do
>>>>> that"? Is this bug slated for a fix next release?
>>>>>
>>>>> Next:
>>>>> Right after all of the 0's, a strong but brief tone is blasted
>>>>> into the tx path. The power of this tone is not affected by the tx
>>>>> gain setting. This is quite a significant problem because we may
>>>>> use this module to test sensitive devices that may not be able to
>>>>> withstand such a transient. Any idea what is causing this? Again,
>>>>> any workarounds or fixes known?
>>>>>
>>>>> I don't care much for the spur at -83dBm. But it would be
>>>>> interesting to understand it.
>>>>>
>>>>> Lastly:
>>>>> The actual waveform is transmitted. Since this is an FSK waveform,
>>>>> I would expect a constant power envelope. Unfortunately, what I
>>>>> capture with the B205i is not even close. I performed the test
>>>>> again, but this time transmitting 200ms of 0s before my actual FSK
>>>>> waveform. You can still see the "warm up" looking behavior,
>>>>> however, by the time the actual waveform hits, the output seems
>>>>> settled. Is that what is happening (warm up)? Preloading every
>>>>> waveform with 200ms of zeroes is extremely undesirable. Is there a
>>>>> way to keep the chip always ready to go from both a Rx and Tx
>>>>> perspective?
>>>>>
>>>>> Tx only with no zeros:
>>>>> I performed the no zeros test again, this time without doing an
>>>>> acquisition with the B205i. Now the warm up behavior is completely
>>>>> gone. Why is Rx influencing the Tx RF performance?
>>>>>
>>>>> Any insight into these issues I am experiencing would be very
>>>>> appreciated.
>>>>>
>>>>> Best regards,
>>>>> Dominik
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> --
>>>>> i.A. Dominik Eyerly
>>>>> Software
>>>>>
>>>>> Tel: +49 (0) 351 7958019 233
>>>>> Fax: +49 (0) 351 7958019 232
>>>>> Email:[email protected]
>>>>> <mailto:[email protected]>
>>>>>
>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>
>>>>> *Support Telefon: +49 (0) 7732 9815 100*
>>>>> [email protected] <mailto:[email protected]>
>>>>> sig
>>>>> Gesch?ftsleitung: Michael Konrad
>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>> Ust-Id-Nr. DE 206693267
>>>>>
>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>>> use of the individual or entity to which it is addressed, and which 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, 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
>>>>> contact us immediately. Thank you.
>>>>> _______________________________________________ USRP-users mailing
>>>>> list [email protected]
>>>>> <mailto:[email protected]>
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> --
>>>
>>> --
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233
>>> Fax: +49 (0) 351 7958019 232
>>> Email:[email protected]
>>> <mailto:[email protected]>
>>>
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>> www.abexstandard.org <http://www.abexstandard.org>
>>>
>>> *Support Telefon: +49 (0) 7732 9815 100*
>>> [email protected] <mailto:[email protected]>
>>> sig
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which 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, 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 contact us
>>> immediately. Thank you.
> --
>
> --
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233
> Fax: +49 (0) 351 7958019 232
> Email:[email protected]
> <mailto:[email protected]>
>
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
> www.konrad-technologies.de <http://www.konrad-technologies.de>
> www.abexstandard.org <http://www.abexstandard.org>
>
> *Support Telefon: +49 (0) 7732 9815 100*
> [email protected] <mailto:[email protected]>
> sig
> Gesch?ftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
> bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
> contains information from Konrad GmbH, which is intended only for the use of
> the individual or entity to which it is addressed, and which 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, 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 contact us immediately. Thank
> you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/58bd9d21/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/58bd9d21/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/58bd9d21/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170405/58bd9d21/attachment-0005.jpe>
------------------------------
Message: 16
Date: Thu, 6 Apr 2017 06:02:56 +0000
From: carry chen <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] more power e3xx device
Message-ID:
<sg2pr06mb080582678cdc29cafe667cc8dd...@sg2pr06mb0805.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi,list
will more powerful e3xx device for sell in the futuren ? zynq 7020<tel:7020>
resource is poor, does have plan to change 7020<tel:7020> to 7035<tel:7035> or
highter?
Thank you!
Carry
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/bf2b5d3b/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 6 Apr 2017 11:07:33 +0200
From: Dominik Eyerly <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
I'm using 1M for both rx and tx. I've seen that example but it does not
have the correct setup to display this behavior. As I mentioned before,
the acquisition has to be running BEFORE transmit begins. In the example
code there is no synchronization between rx start and tx start so you
don't get to see the beginning of the transmit in the capture. I added a
simple atomic bool to the example to ensure rx is running before tx
starts. This is sufficient to display the issue. Also, the issue of
having zeros in rx when creating a streamer will also not be displayed
in this example code because the tx_streamer is created before the
acquisition starts.
Here is a plot of the txrx loopback example with my minor
synchronization addition.
http://imgur.com/a/0FjeI
Would you be able to run the code that I posted in my previous email to
see if you have the same issues on your end?
cheers,
dominik
On 04/06/2017 04:10 AM, Marcus D. Leech wrote:
> On 04/05/2017 10:18 AM, Dominik Eyerly wrote:
>>
>> Hello,
>>
>> UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
>> UHD_3.11.0.git-release, compiled for ARM
>> B205 running on USB3.
>>
>> Doesn't matter if the port is terminated or if it has a signal, recv
>> returns hard 0s, (not 1e-10 or the like) when a tx streamer is
>> created. I've uploaded a simple bit of code that illustrates the
>> behavior quite clearly.
>>
>> https://pastebin.com/ZAccunUe
>>
>> Please note that this code assumes you have 20dB of attenuation
>> between rx and tx. However you can adjust the gain values
>> appropriately if you do not.
>>
>> I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
>> -lboost_system -luhd
>>
>> But honestly, this issue is not my primary concern. My primary
>> concern is the ramp behavior. Note that the code I posted also
>> illustrates the ramping behavior. For this it needs to be in loopback
>> with 20dB attenuation (or more). I included a little helper function
>> which performs a quick dump to a python file. If you have matplotlib
>> for python you can uncomment the "dump_to_py" line in the rx thread
>> and then simply run the generated file with python to see a quick
>> plot of the iq data.
>>
>> What else could I do to further troubleshoot this?
>>
>> cheers,
>> Dominik
>>
> There is an example program, called txrx_loopback_to_file that does
> something similar to your test.
>
> I wonder if it would be possible to do your tests with that, and see
> if there is any change in behavior.
>
> Also, what sample rates are you using?
>
>
>>
>> On 04/05/2017 02:25 PM, Marcus D. Leech wrote:
>>> On 04/05/2017 05:57 AM, Dominik Eyerly wrote:
>>>>
>>>> Hello,
>>>>
>>>> Thanks for the reply. I should add I am doing this test at 3.8G.
>>>>
>>>> Response to (A)
>>>>
>>>> Are you saying that regardless of my tx gain setting, I need 40dB
>>>> of attenuation? I believe at max tx gain the board outputs around
>>>> 10-15dBm @3.8G. I currently have a 6dB pad on tx port, cabled to a
>>>> splitter which is cabled to the rx port with an inline 10dB pad.
>>>> The other splitter port is going directly into my VSA. Also, my tx
>>>> gain is around 50dB. My understanding was that the max input power
>>>> of the rx port is -15dBm. With this configuration I should be well
>>>> under that, as shown on my VSA capture (~-35dBm).
>>>>
>>>> Response to (B)
>>>>
>>>> According to the rough specifications posted here:
>>>> https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>>>
>>>> The IIP3 is -15dBm. As you can see on my VSA capture, it received
>>>> -35dBm and that doesn't even include the extra 10dB pad on the
>>>> ettus rx port. I should be good on linearity, should I not? The
>>>> reason the power capture looks so wavy is probably because I have
>>>> the LO's tuned to the same spot. When I move tx off by 100kHz the
>>>> capture looks "nicer" but the ramp up behavior is still there.
>>>> Also, on the link I posted above, the max input power is called out
>>>> as 0 dBm... is that correct?
>>>>
>>>> Could you provide some input on the questions I brought up in my
>>>> previous email? Namely:
>>>>
>>>> (1) recv returning 0s when a tx_streamer is created while receiving
>>>> continuously.
>>>>
>>> Could you try a simple experiment here? Place a terminator on the
>>> input to the RX side, and see if you get 0s in the recv buffer. I
>>> want to distinguish
>>> between an analog situation and a digital one.
>>>
>>>> (2) The ramp up behavior that is only present when transmitting
>>>> during an active acquisition.
>>>>
>>> That's odd. What version of UHD are you using?
>>>
>>>
>>>> I also want to mention that the first burst of power in my captures
>>>> coincides with changing the frequency of the tx LO. This triggers
>>>> an internal calibration of the AD chip which in turn outputs this
>>>> brief burst. So at least this mystery is solved. I am curious,
>>>> however, is it possible to allow the chip to perform its cal
>>>> without actually seeing this signal at the tx port?
>>>>
>>> I'm not certain of exactly how it performs its calibration, but
>>> likely there will always be some leakage when it is doing so.
>>>
>>>
>>>> cheers,
>>>> Dominik
>>>>
>>>>
>>>> On 04/04/2017 04:54 PM, [email protected] wrote:
>>>>>
>>>>> How are you doing the physical loop-back? If directly-cabled,
>>>>> you'll need about 40dB of attenuation in-line, to keep the
>>>>> receiver from:
>>>>>
>>>>> (A) Being damaged
>>>>>
>>>>> (B) Remaining linear
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2017-04-04 09:14, Dominik Eyerly via USRP-users wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> My questions concern the B205i. I've uploaded some pictures to
>>>>>> simplify the explaining process.
>>>>>>
>>>>>> http://imgur.com/a/XMAv6
>>>>>>
>>>>>> Basically, I want to transmit and receive a FSK waveform on one
>>>>>> board (loopback). This means I've tuned both LOs to the same
>>>>>> frequency. I've also inserted a splitter to be able to look at
>>>>>> the signal on my VSA. This has allowed me to identify several
>>>>>> problems.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Let's start on the left:
>>>>>> (B205i Receive - no zeros)
>>>>>> Here you see the received power drop from the noise floor to
>>>>>> -infinity because the rx_streamer was returning 0's. I've tracked
>>>>>> this problem to the creation of a tx_streamer while an
>>>>>> acquisition is running. This seems completely unacceptable; that
>>>>>> calling a command on a chain (tx) that has nothing to do with rx,
>>>>>> has an effect on rx. I could understand that the sample rate
>>>>>> performance of rx is affected because they share a communication
>>>>>> link, but not to actually alter the data that is returned by the
>>>>>> recv call. Is this a known bug? Is there a workaround other than
>>>>>> "don't do that"? Is this bug slated for a fix next release?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Next:
>>>>>> Right after all of the 0's, a strong but brief tone is blasted
>>>>>> into the tx path. The power of this tone is not affected by the
>>>>>> tx gain setting. This is quite a significant problem because we
>>>>>> may use this module to test sensitive devices that may not be
>>>>>> able to withstand such a transient. Any idea what is causing
>>>>>> this? Again, any workarounds or fixes known?
>>>>>>
>>>>>>
>>>>>>
>>>>>> I don't care much for the spur at -83dBm. But it would be
>>>>>> interesting to understand it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Lastly:
>>>>>> The actual waveform is transmitted. Since this is an FSK
>>>>>> waveform, I would expect a constant power envelope.
>>>>>> Unfortunately, what I capture with the B205i is not even close. I
>>>>>> performed the test again, but this time transmitting 200ms of 0s
>>>>>> before my actual FSK waveform. You can still see the "warm up"
>>>>>> looking behavior, however, by the time the actual waveform hits,
>>>>>> the output seems settled. Is that what is happening (warm up)?
>>>>>> Preloading every waveform with 200ms of zeroes is extremely
>>>>>> undesirable. Is there a way to keep the chip always ready to go
>>>>>> from both a Rx and Tx perspective?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Tx only with no zeros:
>>>>>> I performed the no zeros test again, this time without doing an
>>>>>> acquisition with the B205i. Now the warm up behavior is
>>>>>> completely gone. Why is Rx influencing the Tx RF performance?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Any insight into these issues I am experiencing would be very
>>>>>> appreciated.
>>>>>>
>>>>>> Best regards,
>>>>>> Dominik
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> i.A. Dominik Eyerly
>>>>>> Software
>>>>>>
>>>>>> Tel: +49 (0) 351 7958019 233
>>>>>> Fax: +49 (0) 351 7958019 232
>>>>>> Email: [email protected]
>>>>>> <mailto:[email protected]>
>>>>>>
>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>
>>>>>> *Support Telefon: +49 (0) 7732 9815 100*
>>>>>> [email protected]
>>>>>> <mailto:[email protected]>
>>>>>> sig
>>>>>> Gesch?ftsleitung: Michael Konrad
>>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>>> Ust-Id-Nr. DE 206693267
>>>>>>
>>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen
>>>>>> Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>>
>>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may
>>>>>> accompany it, contains information from Konrad GmbH, which is intended
>>>>>> only for the use of the individual or entity to which it is addressed,
>>>>>> and which 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, 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 contact us immediately. Thank you.
>>>>>> _______________________________________________ USRP-users
>>>>>> mailing list [email protected]
>>>>>> <mailto:[email protected]>
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>> --
>>>>
>>>> --
>>>> i.A. Dominik Eyerly
>>>> Software
>>>>
>>>> Tel: +49 (0) 351 7958019 233
>>>> Fax: +49 (0) 351 7958019 232
>>>> Email: [email protected]
>>>> <mailto:[email protected]>
>>>>
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>
>>>> *Support Telefon: +49 (0) 7732 9815 100*
>>>> [email protected] <mailto:[email protected]>
>>>> sig
>>>> Gesch?ftsleitung: Michael Konrad
>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>> Ust-Id-Nr. DE 206693267
>>>>
>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>
>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>> use of the individual or entity to which it is addressed, and which 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, 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
>>>> contact us immediately. Thank you.
>> --
>>
>> --
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233
>> Fax: +49 (0) 351 7958019 232
>> Email: [email protected]
>> <mailto:[email protected]>
>>
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>> www.abexstandard.org <http://www.abexstandard.org>
>>
>> *Support Telefon: +49 (0) 7732 9815 100*
>> [email protected] <mailto:[email protected]>
>> sig
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which 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, 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 contact us
>> immediately. Thank you.
--
--
i.A. Dominik Eyerly
Software
Tel: +49 (0) 351 7958019 233
Fax: +49 (0) 351 7958019 232
Email: [email protected]
<mailto:[email protected]>
*Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
www.konrad-technologies.de <http://www.konrad-technologies.de>
www.abexstandard.org <http://www.abexstandard.org>
*Support Telefon: +49 (0) 7732 9815 100*
[email protected] <mailto:[email protected]>
sig
Gesch?ftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267
VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person
bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen
sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind
verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie
nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke
CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
contains information from Konrad GmbH, which is intended only for the use of
the individual or entity to which it is addressed, and which 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, 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 contact us immediately. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/f541be93/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/f541be93/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/f541be93/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/f541be93/attachment-0005.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/f541be93/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/f541be93/attachment-0001.asc>
------------------------------
Message: 18
Date: Thu, 6 Apr 2017 17:27:31 +0800
From: john liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] about FPGA x310
Message-ID:
<caf6nnt+yeoddrd42zc+mokhc7gurhnowud+jfpqbc-vfdn7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
We found that the noc_shell.v file debug [31:0] signal in USRP X310 FPGA
code, how they are used? What tools to debug you are use?
We used Chipscope online debugging FPGA code now ,because we are not
familiar with vivado software.
thank you.
best regards
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/50ab4b26/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 6 Apr 2017 15:38:07 +0500
From: Jalal Shams <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] No UHD Device error
Message-ID:
<CAMnwUyR4UCe56_ymyijeKUikxm6=ye3aiThtKAWz=kfefiz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks, yes I also think I have to get the thing on metal :) . In ubuntu
16.04 sytemd is used instead of Upstart, would it be feasible considering
that ? I will update my distro and drivers and then let you know.
As far as GNU radio is concerned, it's not in my hands as I have been given
the project by my university and they want it that way :(
Jalal
On Thu, Apr 6, 2017 at 5:05 AM, Neel Pandeya <[email protected]> wrote:
> Please keep the conversation on the mailing list.
>
> I'll respond to you more there.
>
> --?Neel Pandeya
>
>
>
>
> On 5 April 2017 at 16:00, Jalal Shams <[email protected]> wrote:
>
>> Thanks, yes I also think I have to get the thing on metal :) . In ubuntu
>> 16.04 sytemd is used instead of Upstart, would it be feasible considering
>> that ? I will update my distro and drivers and then let you know.
>>
>> As far as GNU radio is concerned, it's not in my hands as I have been
>> given the project by my university and they want it that way :(
>>
>> On Thu, Apr 6, 2017 at 3:53 AM, Neel Pandeya <[email protected]>
>> wrote:
>>
>>> Hello Jalal:
>>>
>>> Several comments....
>>>
>>> I would not recommend using a VM. First get things working on-the-metal.
>>> The VM will limit throughput, and will require some configuration settings
>>> for USB and Ethernet connections.
>>>
>>> From your screenshot, you're using UHD 3.8.0, which is quite old. I
>>> would recommend using UHD 3.9.6.
>>>
>>> You said you're using Ubuntu 12.04, which is also quite old. Again, I
>>> would recommend using something newer, Ubuntu 16.04 ideally.
>>>
>>> But the most important thing is to ask why you want to port OpenBTS to
>>> GNU Radio? I cannot think of any reason to do this, and GNU Radio is not
>>> well-suited for implementing applications such as cellular stacks (i.e.,
>>> OpenBTS). There is a reason why none of the cellular stacks use GNU Radio.
>>>
>>> --?Neel Pandeya
>>>
>>>
>>>
>>>
>>> On 5 April 2017 at 15:05, Jalal Shams via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> In addition I am using Virtual box
>>>>
>>>> On Thu, Apr 6, 2017 at 3:04 AM, Jalal Shams <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>> I am working on implementing OpenBts on Gnuradio. In doing so I am
>>>>> getting the same error as shown in the picture. This picture is of Ubuntu
>>>>> 12.04 as I was following "Getting started with Openbts" but I got the same
>>>>> error when I was using Ubuntu 14.04.
>>>>> I am using USRP 2 device of ettus research and I am wondering what is
>>>>> it that I am doing wrong ? One thing is that I am not getting the ethernet
>>>>> lights and when I ping to the default IP of USRP i-e 192.168.10.2 I get
>>>>> "DESTINATION HOST UNREACHABLE" (though I have tried various cables and
>>>>> also provided static host IP)
>>>>> [image: Inline image 1]
>>>>>
>>>>> I will be thankful to you guys
>>>>> Jalal
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20170406/c8589462/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 77107 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/c8589462/attachment-0001.png>
------------------------------
Message: 20
Date: Thu, 6 Apr 2017 10:28:40 -0400
From: EJ Kreinar <[email protected]>
To: Nick Foster <[email protected]>
Cc: Philip Balister <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Generating custom FSBL for E310
Message-ID:
<cadrnh220psw-nhunpgbwabjp-dorugky3mqak0pdfbbcqwr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for clarifying! My education was apparently missing the ps7_init.c
configuration.
I'm curious to see how you end up regenerating ps7_init.c... It would be
nice to understand the full workflow to reconfigure the E300 PS.
Good luck!
EJ
On Tue, Apr 4, 2017 at 12:11 PM, Nick Foster <[email protected]> wrote:
> Comments inline.
> On Tue, Apr 4, 2017, 8:13 AM EJ Kreinar <[email protected]> wrote:
>
> Hi guys,
>
> I've been following along and I have a couple questions. I'm a novice in
> this area, but I *thought* I generally understood how this image generation
> process works, so I'd just like to make sure to clarify a few points...
>
> 1. First, just backing up the truck a bit... I'm confused why the FSBL is
> responsible for enabling I2C. From my understanding, the FSBL is generally
> responsible for loading bitstream, uboot, uimage, and the device tree blob.
> (Alternatively, in the meta-xilinx repo, the FSBL contains a SPL that does
> a similar job of loading bitstream and DTB). Is this how the E300 FSBL and
> uboot work? If so, I would think the device tree is ultimately responsible
> for assigning I2C to the correct pins and loading the relevant driver (not
> the FSBL). Is this correct?
>
>
> Vivado generates ps7_init.c/h which are responsible for configuring the PS
> appropriately given the PS7 IP configuration specified in the project. In
> ordinary use you use the SDK to compile an FSBL which uses ps7_init.c to
> initialize and configure the CPU, clocks, and peripherals. In the E300 BSP
> it appears as though u-boot is responsible for handling this. I know that
> certain u-boot configurations (u-boot-spl) can bypass FSBL entirely. I
> haven't had time to look yet (PB, want to comment?) but I suspect that's
> the case here.
>
>
>
> 2. If what you need is a new device tree, I would think there's two
> typical options. Is this correct for the E300?
> a. For some Xilinx builds, you can create a dtb like this:
> http://www.wiki.xilinx.com/Build+Device+Tree+Blob
> b. But, for meta-ettus, it looks like bitbake is building the device
> tree blob using the dts in the meta-ettus repo. Would you just want to make
> a patch on top of this plain-text file with I2C attached to the desired
> pins?
>
>
> Yes, this has been done already.
>
>
>
> 3. If you really need to export the Vivado IP to the SDK, does it make
> sense to run your FPGA build command using something like "make E310 GUI=1"
> to bring up the Vivado GUI, save off the vivado project, and then export
> your hardware from there?
>
>
> Yes, this is the approach I was trying to use. Without a top-level block
> diagram Vivado won't generate the appropriate definitions to export
> hardware to the SDK.
>
>
>
>
> Finally, can we summarize the overall changes necessary so I can see the
> big picture? Here's my list-- Please indicate what's wrong or missing:
> 1. Updated FPGA image with PS mods to support I2C and correct
> routing/constraints. This can be inserted into the bitbake build as Phil
> suggested, but it could also be programmed to the FPGA from userspace once
> the board is brought up if necessary (cat xxx.bit > /dev/xdevcfg)
> 2. I2C kernel driver. If the E300 build did not already include I2C in
> the kernel, you'd want to add this to the kernel.
> 3. Device tree connecting I2C driver to correct pins.
> 4. Anything else??
>
>
> 5. I2C hardware needs to be enabled and given a clock so that the device
> tree can find it. This is what ps7_init.c does.
>
> --n
>
>
>
> Thanks for entertaining my novice questions :)
>
> EJ
>
> On Tue, Apr 4, 2017 at 6:46 AM, Philip Balister via USRP-users <
> [email protected]> wrote:
>
> On 04/03/2017 06:25 PM, Philip Balister via USRP-users wrote:
> > On 04/03/2017 04:08 PM, Nick Foster via USRP-users wrote:
> >> Hey all,
> >>
> >> This is a little off the beaten path for E310, but I know there's
> someone
> >> here who can help.
> >>
> >> I've enabled I2C1 on E310 and routed it via EMIO to the GPIO header J12.
> >> I've added it and its connected devices to the device tree, I've
> recompiled
> >> a kernel to work with the connected devices, I've reconfigured the PS7
> IP,
> >> routed it all through the top level Verilog, added IOBUFs for the
> tristate
> >> pins, and built images. However, the FSBL in the default distribution
> >> doesn't enable I2C1 or configure it for EMIO, so I need to compile one
> and
> >> generate a boot image which does.
> >>
> >> However, because there isn't a block diagram associated with the E300
> >> project, I can't seem to export the hardware definition for the SDK. Can
> >> someone who's been down this road clue me in as to how to get Vivado to
> >> export hardware from the E300 project to the SDK?
> >
> > The Xilinx process for building fsbl is painful.
> >
> > I'd like to say the E300 bsp has a less painful process, but there where
> > some issues churning at that time, so it isn't :)
> >
> > I did a quick review of what gets built and i think the ps7* files are
> > injected into the u-boot here:
> >
> > https://github.com/EttusResearch/meta-ettus/blob/
> jethro/recipes-bsp/u-boot/u-boot-2015.10/0002-zynq-e3xx-
> split-up-in-speedgrades.patch
> >
> > Which is annoying since they are lumped in with a bunch of other code :(
> >
> > Modern u-boot recipes are much cleaner, and I see we should work on
> > deleting dead code from the E300 BSP to reduce confusion.
>
> After thinking some more, I think the easiest approach is use a _prepend
> to the configure step in the recipe to copy the new ps7 files into the
> source tree. This would over write the ones created from the patches in
> the recipe.
>
> Philip
>
>
> >
> > Philip
> >
> >
> >>
> >> Thanks!
> >> Nick
> >>
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected]
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> 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/20170406/c1470426/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 06 Apr 2017 16:43:15 +0200
From: Francois Quitin <[email protected]>
To: [email protected]
Subject: [USRP-users] disabling LO correction on E310 and B205mini-i
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Dear list,
I am running an experiment where a B205mini-i is sending a LTE PSS every
5 millisecond. This is received by a E310, which correlated the received
baseband samples with the PSS to extract the received packets.
When I look at the phase of the received packets, I obtain the attached
graph. The phase of the received packets drifts linearly most of the
time, as expected due to LO offset. However, I always have a moment when
the LO offset seems to self-correct (around packet 300 in the attached
graph) and then go the other way.
I assume that this is due LO self-correction in the TCXO modules, is
this correct? If so, is there a way that I can deactivate this? I would
rather have a large but predictable LO offset than one that's small but
unpredictable... I already tried putting the reference of the B205 to
"external" and the time source of the E310 to "external", but it didn't
help.
Thanks a lot,
Francois
---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phase_rx_packets.png
Type: image/png
Size: 31376 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/fb52d5ce/attachment-0001.png>
------------------------------
Message: 22
Date: Thu, 6 Apr 2017 09:12:08 -0600
From: Steven Knudsen <[email protected]>
To: Francois Quitin <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] disabling LO correction on E310 and
B205mini-i
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Francois,
I am pretty sure what you have managed to capture is the so-called ?1PPS
sawtooth?. A while back I did a lot of work with timing and in testing various
GPS modules it was easy to produce that plot.
You can google ?1PPS sawtooth? and turn up lots of discussion. One of the more
interesting links is http://www.gpstime.com/files/TOW/tow-time2011.pdf
<http://www.gpstime.com/files/TOW/tow-time2011.pdf> where on slides 23-25 you
can see the same thing as you posted.
So, this is not due to TCXO correction (unless they are VTCXO and some external
controller is mimicking what a GPS microcontroller does).
Hope that helps.
PS you might want to turn off the plot point symbols to see this more clearly.
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
An Fortschritt glauben hei?t nicht glauben, da? ein Fortschritt schon geschehen
ist. Das w?re kein Glauben. - Franz Kafka
Post hoc ergo propter hoc.
> On Apr 6, 2017, at 08:43, Francois Quitin via USRP-users
> <[email protected]> wrote:
>
> Dear list,
>
> I am running an experiment where a B205mini-i is sending a LTE PSS every 5
> millisecond. This is received by a E310, which correlated the received
> baseband samples with the PSS to extract the received packets.
>
> When I look at the phase of the received packets, I obtain the attached
> graph. The phase of the received packets drifts linearly most of the time, as
> expected due to LO offset. However, I always have a moment when the LO offset
> seems to self-correct (around packet 300 in the attached graph) and then go
> the other way.
>
> I assume that this is due LO self-correction in the TCXO modules, is this
> correct? If so, is there a way that I can deactivate this? I would rather
> have a large but predictable LO offset than one that's small but
> unpredictable... I already tried putting the reference of the B205 to
> "external" and the time source of the E310 to "external", but it didn't help.
>
> Thanks a lot,
> Francois
>
> ---
> <phase_rx_packets.png>_______________________________________________
> 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/20170406/b60e0ad2/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 06 Apr 2017 11:51:32 -0400
From: "Marcus D. Leech" <[email protected]>
To: Dominik Eyerly <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B205i transient behavior
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/06/2017 05:07 AM, Dominik Eyerly wrote:
>
> I'm using 1M for both rx and tx. I've seen that example but it does
> not have the correct setup to display this behavior. As I mentioned
> before, the acquisition has to be running BEFORE transmit begins. In
> the example code there is no synchronization between rx start and tx
> start so you don't get to see the beginning of the transmit in the
> capture. I added a simple atomic bool to the example to ensure rx is
> running before tx starts. This is sufficient to display the issue.
> Also, the issue of having zeros in rx when creating a streamer will
> also not be displayed in this example code because the tx_streamer is
> created before the acquisition starts.
>
> Here is a plot of the txrx loopback example with my minor
> synchronization addition.
>
> http://imgur.com/a/0FjeI
>
> Would you be able to run the code that I posted in my previous email
> to see if you have the same issues on your end?
>
>
> cheers,
> dominik
>
>
OK, so, with the zeros, I think I understand what's going on. When you
create a new streamer, the hardware has to be configured to the new state.
In the case of the AD9361, this means the data path between the
AD9361 and the FPGA, which unavoidably means that the RX samples are
interrupted
while the interface is reconfigured. I believe this is the reason
for a lump of zeros when you configure for TX--someone in engineering
can correct
my understanding if it's wrong.
In terms of the rather-long transient time--is this only immediately
after configuring the TX streamer, or for any TX burst? If it's just
immediately
after configuring a TX streamer, then this may be expected. If it's
at the start of every burst, then something is very wrong. Again, I'm
awaiting
comment from someone in Ettus R&D.
> On 04/06/2017 04:10 AM, Marcus D. Leech wrote:
>> On 04/05/2017 10:18 AM, Dominik Eyerly wrote:
>>>
>>> Hello,
>>>
>>> UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
>>> UHD_3.11.0.git-release, compiled for ARM
>>> B205 running on USB3.
>>>
>>> Doesn't matter if the port is terminated or if it has a signal, recv
>>> returns hard 0s, (not 1e-10 or the like) when a tx streamer is
>>> created. I've uploaded a simple bit of code that illustrates the
>>> behavior quite clearly.
>>>
>>> https://pastebin.com/ZAccunUe
>>>
>>> Please note that this code assumes you have 20dB of attenuation
>>> between rx and tx. However you can adjust the gain values
>>> appropriately if you do not.
>>>
>>> I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
>>> -lboost_system -luhd
>>>
>>> But honestly, this issue is not my primary concern. My primary
>>> concern is the ramp behavior. Note that the code I posted also
>>> illustrates the ramping behavior. For this it needs to be in
>>> loopback with 20dB attenuation (or more). I included a little
>>> helper function which performs a quick dump to a python file. If you
>>> have matplotlib for python you can uncomment the "dump_to_py" line
>>> in the rx thread and then simply run the generated file with python
>>> to see a quick plot of the iq data.
>>>
>>> What else could I do to further troubleshoot this?
>>>
>>> cheers,
>>> Dominik
>>>
>> There is an example program, called txrx_loopback_to_file that does
>> something similar to your test.
>>
>> I wonder if it would be possible to do your tests with that, and see
>> if there is any change in behavior.
>>
>> Also, what sample rates are you using?
>>
>>
>>>
>>> On 04/05/2017 02:25 PM, Marcus D. Leech wrote:
>>>> On 04/05/2017 05:57 AM, Dominik Eyerly wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Thanks for the reply. I should add I am doing this test at 3.8G.
>>>>>
>>>>> Response to (A)
>>>>>
>>>>> Are you saying that regardless of my tx gain setting, I need 40dB
>>>>> of attenuation? I believe at max tx gain the board outputs around
>>>>> 10-15dBm @3.8G. I currently have a 6dB pad on tx port, cabled to a
>>>>> splitter which is cabled to the rx port with an inline 10dB pad.
>>>>> The other splitter port is going directly into my VSA. Also, my
>>>>> tx gain is around 50dB. My understanding was that the max input
>>>>> power of the rx port is -15dBm. With this configuration I should
>>>>> be well under that, as shown on my VSA capture (~-35dBm).
>>>>>
>>>>> Response to (B)
>>>>>
>>>>> According to the rough specifications posted here:
>>>>> https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>>>>
>>>>> The IIP3 is -15dBm. As you can see on my VSA capture, it received
>>>>> -35dBm and that doesn't even include the extra 10dB pad on the
>>>>> ettus rx port. I should be good on linearity, should I not? The
>>>>> reason the power capture looks so wavy is probably because I have
>>>>> the LO's tuned to the same spot. When I move tx off by 100kHz the
>>>>> capture looks "nicer" but the ramp up behavior is still there.
>>>>> Also, on the link I posted above, the max input power is called
>>>>> out as 0 dBm... is that correct?
>>>>>
>>>>> Could you provide some input on the questions I brought up in my
>>>>> previous email? Namely:
>>>>>
>>>>> (1) recv returning 0s when a tx_streamer is created while
>>>>> receiving continuously.
>>>>>
>>>> Could you try a simple experiment here? Place a terminator on the
>>>> input to the RX side, and see if you get 0s in the recv buffer. I
>>>> want to distinguish
>>>> between an analog situation and a digital one.
>>>>
>>>>> (2) The ramp up behavior that is only present when transmitting
>>>>> during an active acquisition.
>>>>>
>>>> That's odd. What version of UHD are you using?
>>>>
>>>>
>>>>> I also want to mention that the first burst of power in my
>>>>> captures coincides with changing the frequency of the tx LO. This
>>>>> triggers an internal calibration of the AD chip which in turn
>>>>> outputs this brief burst. So at least this mystery is solved. I am
>>>>> curious, however, is it possible to allow the chip to perform its
>>>>> cal without actually seeing this signal at the tx port?
>>>>>
>>>> I'm not certain of exactly how it performs its calibration, but
>>>> likely there will always be some leakage when it is doing so.
>>>>
>>>>
>>>>> cheers,
>>>>> Dominik
>>>>>
>>>>>
>>>>> On 04/04/2017 04:54 PM, [email protected] wrote:
>>>>>>
>>>>>> How are you doing the physical loop-back? If directly-cabled,
>>>>>> you'll need about 40dB of attenuation in-line, to keep the
>>>>>> receiver from:
>>>>>>
>>>>>> (A) Being damaged
>>>>>>
>>>>>> (B) Remaining linear
>>>>>>
>>>>>> On 2017-04-04 09:14, Dominik Eyerly via USRP-users wrote:
>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> My questions concern the B205i. I've uploaded some pictures to
>>>>>>> simplify the explaining process.
>>>>>>>
>>>>>>> http://imgur.com/a/XMAv6
>>>>>>>
>>>>>>> Basically, I want to transmit and receive a FSK waveform on one
>>>>>>> board (loopback). This means I've tuned both LOs to the same
>>>>>>> frequency. I've also inserted a splitter to be able to look at
>>>>>>> the signal on my VSA. This has allowed me to identify several
>>>>>>> problems.
>>>>>>>
>>>>>>> Let's start on the left:
>>>>>>> (B205i Receive - no zeros)
>>>>>>> Here you see the received power drop from the noise floor to
>>>>>>> -infinity because the rx_streamer was returning 0's. I've
>>>>>>> tracked this problem to the creation of a tx_streamer while an
>>>>>>> acquisition is running. This seems completely unacceptable; that
>>>>>>> calling a command on a chain (tx) that has nothing to do with
>>>>>>> rx, has an effect on rx. I could understand that the sample rate
>>>>>>> performance of rx is affected because they share a communication
>>>>>>> link, but not to actually alter the data that is returned by the
>>>>>>> recv call. Is this a known bug? Is there a workaround other than
>>>>>>> "don't do that"? Is this bug slated for a fix next release?
>>>>>>>
>>>>>>> Next:
>>>>>>> Right after all of the 0's, a strong but brief tone is blasted
>>>>>>> into the tx path. The power of this tone is not affected by the
>>>>>>> tx gain setting. This is quite a significant problem because we
>>>>>>> may use this module to test sensitive devices that may not be
>>>>>>> able to withstand such a transient. Any idea what is causing
>>>>>>> this? Again, any workarounds or fixes known?
>>>>>>>
>>>>>>> I don't care much for the spur at -83dBm. But it would be
>>>>>>> interesting to understand it.
>>>>>>>
>>>>>>> Lastly:
>>>>>>> The actual waveform is transmitted. Since this is an FSK
>>>>>>> waveform, I would expect a constant power envelope.
>>>>>>> Unfortunately, what I capture with the B205i is not even close.
>>>>>>> I performed the test again, but this time transmitting 200ms of
>>>>>>> 0s before my actual FSK waveform. You can still see the "warm
>>>>>>> up" looking behavior, however, by the time the actual waveform
>>>>>>> hits, the output seems settled. Is that what is happening (warm
>>>>>>> up)? Preloading every waveform with 200ms of zeroes is extremely
>>>>>>> undesirable. Is there a way to keep the chip always ready to go
>>>>>>> from both a Rx and Tx perspective?
>>>>>>>
>>>>>>> Tx only with no zeros:
>>>>>>> I performed the no zeros test again, this time without doing an
>>>>>>> acquisition with the B205i. Now the warm up behavior is
>>>>>>> completely gone. Why is Rx influencing the Tx RF performance?
>>>>>>>
>>>>>>> Any insight into these issues I am experiencing would be very
>>>>>>> appreciated.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Dominik
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> i.A. Dominik Eyerly
>>>>>>> Software
>>>>>>>
>>>>>>> Tel: +49 (0) 351 7958019 233
>>>>>>> Fax: +49 (0) 351 7958019 232
>>>>>>> Email:[email protected]
>>>>>>> <mailto:[email protected]>
>>>>>>>
>>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>>
>>>>>>> *Support Telefon: +49 (0) 7732 9815 100*
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> sig
>>>>>>> Gesch?ftsleitung: Michael Konrad
>>>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>>>> Ust-Id-Nr. DE 206693267
>>>>>>>
>>>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen
>>>>>>> Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>>>
>>>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may
>>>>>>> accompany it, contains information from Konrad GmbH, which is intended
>>>>>>> only for the use of the individual or entity to which it is addressed,
>>>>>>> and which 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, 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 contact us immediately. Thank you.
>>>>>>> _______________________________________________ USRP-users
>>>>>>> mailing list [email protected]
>>>>>>> <mailto:[email protected]>
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>> --
>>>>>
>>>>> --
>>>>> i.A. Dominik Eyerly
>>>>> Software
>>>>>
>>>>> Tel: +49 (0) 351 7958019 233
>>>>> Fax: +49 (0) 351 7958019 232
>>>>> Email:[email protected]
>>>>> <mailto:[email protected]>
>>>>>
>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>
>>>>> *Support Telefon: +49 (0) 7732 9815 100*
>>>>> [email protected] <mailto:[email protected]>
>>>>> sig
>>>>> Gesch?ftsleitung: Michael Konrad
>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>> Ust-Id-Nr. DE 206693267
>>>>>
>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>>> use of the individual or entity to which it is addressed, and which 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, 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
>>>>> contact us immediately. Thank you.
>>> --
>>>
>>> --
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233
>>> Fax: +49 (0) 351 7958019 232
>>> Email:[email protected]
>>> <mailto:[email protected]>
>>>
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>> www.abexstandard.org <http://www.abexstandard.org>
>>>
>>> *Support Telefon: +49 (0) 7732 9815 100*
>>> [email protected] <mailto:[email protected]>
>>> sig
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which 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, 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 contact us
>>> immediately. Thank you.
> --
>
> --
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233
> Fax: +49 (0) 351 7958019 232
> Email:[email protected]
> <mailto:[email protected]>
>
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
> www.konrad-technologies.de <http://www.konrad-technologies.de>
> www.abexstandard.org <http://www.abexstandard.org>
>
> *Support Telefon: +49 (0) 7732 9815 100*
> [email protected] <mailto:[email protected]>
> sig
> Gesch?ftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
> bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
> contains information from Konrad GmbH, which is intended only for the use of
> the individual or entity to which it is addressed, and which 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, 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 contact us immediately. Thank
> you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/c6960418/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/c6960418/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/c6960418/attachment-0005.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/c6960418/attachment-0006.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170406/c6960418/attachment-0007.jpe>
------------------------------
Message: 24
Date: Thu, 6 Apr 2017 11:54:50 -0400
From: EJ Kreinar <[email protected]>
To: Francois Quitin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] disabling LO correction on E310 and
B205mini-i
Message-ID:
<cadrnh20froj7jcv+wifqn9sxaaylz10jy8epafjw4mibumq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Francois,
I dont think this is a GPS 1 PPS sawtooth.
> I assume that this is due LO self-correction in the TCXO modules, is this
correct? If so, is there a way that I can deactivate this? I would rather
have a large but predictable LO offset than one that's small but
unpredictable
This is a classic example of LO offset, as you described. Because you are
using physically different devices for transmitter and receiver, their
internal clocks drift over time. When the LO offset "self-corrects," you're
seeing the clocks drift into and out of alignment. A fun plot would be to
show the frequency drift between oscillators (take the first difference of
the phase, divide by time between samples). Unfortunately, there's no easy
LO offset correction that synchronizes remote oscillators.
However, this is a very very common problem. When communication systems
perform "carrier recovery" they're getting rid of this phase drift. You can
use a PLL, you can track this phase via software; there's lots of different
ways you can remove the drifting phase. I expect LTE has a standard
approach to correct frequency offset. I also imagine there's a few gnuradio
blocks you can use (maybe even out of the box) that do carrier recovery-- I
dont know off the top of my head, but I'm sure someone on the mailing list
knows :)
Regarding the "external" source, there's a couple reasons why this would
not remove the LO offset. First, make sure you have the correct input going
in to the device. Obvious, but always worth a check. Second, the actual
implementation is very important. If you're providing a common 10 MHz
reference to the E300/B200, you need to check that the "external" mode
explicitly uses the 10 MHz reference IN PLACE OF the onboard 40 MHz VCTCXO
(or some very tight control loop). I dont remember if it does. Otherwise,
you will not have LO synchronization at your carrier frequency. I would not
expect GPS or PPS external inputs to achieve perfect LO synchronization. To
illustrate why- if the 40 MHz oscillator walks just 1 Hz within one second,
an LO at 2.4 GHz will see a change of 60 Hz, which is a phase wrap of 60
times per second. You'll see that in your results. It's very difficult to
perfectly synchronize remote LOs without explicitly sharing a clock
reference.
Cheers,
EJ
On Thu, Apr 6, 2017 at 10:43 AM, Francois Quitin via USRP-users <
[email protected]> wrote:
> Dear list,
>
> I am running an experiment where a B205mini-i is sending a LTE PSS every 5
> millisecond. This is received by a E310, which correlated the received
> baseband samples with the PSS to extract the received packets.
>
> When I look at the phase of the received packets, I obtain the attached
> graph. The phase of the received packets drifts linearly most of the time,
> as expected due to LO offset. However, I always have a moment when the LO
> offset seems to self-correct (around packet 300 in the attached graph) and
> then go the other way.
>
> I assume that this is due LO self-correction in the TCXO modules, is this
> correct? If so, is there a way that I can deactivate this? I would rather
> have a large but predictable LO offset than one that's small but
> unpredictable... I already tried putting the reference of the B205 to
> "external" and the time source of the E310 to "external", but it didn't
> help.
>
> Thanks a lot,
> Francois
>
> ---
>
> _______________________________________________
> 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/20170406/71565687/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 80, Issue 6
*****************************************
