Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Which versions of uhd, gnuradio, and gr-ettus will run
the radio gr-ettus examples without crashing on the X310?
(Jonathon Pendlum)
2. X310 transmit underflow when sampling rate is low
(Hood, Christopher L.)
3. Re: rfnoc-modtool cores (EJ Kreinar)
4. Multiple timed bursts on X300 (Jacob Knoles)
5. Complex FFT display of Frequency offset. (Walter Maguire)
6. Complex FFT Display Follow-up (Walter Maguire)
7. start/stop usrp perfect (carry chen)
8. Re: rx_samples_to_file bandwidth does not take effect (olivani)
9. Re: rx_samples_to_file bandwidth does not take effect
(Marcus M?ller)
10. Re: weird E310 libboost update problem (Jason Matusiak)
11. E310 gnuradio not showing RFNoC blocks (Jason Matusiak)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Jun 2017 13:07:03 -0700
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Which versions of uhd, gnuradio, and
gr-ettus will run the radio gr-ettus examples without crashing on the
X310?
Message-ID:
<cagdo0uswhsm9agwtyrdgrdsiru9xrdnntuimyeg2nefav+w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have used RFNoC on Ubuntu 14.04 and 16.04. Haven't tried 15.04, but I
don't see any reason why it wouldn't work.
Are you getting any error messages? Have you tried installed RFNoC bia
PyBOMBs?
On Wed, Jun 21, 2017 at 4:15 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> I am having trouble running the RFNoC Radio gr-ettus/examples/rfnoc
> specific flowgraphs without crashing. In particular, the ones that are
> giving me trouble are rfnoc_tx.grc, rfnoc_rxtx.grc, rfnoc_ddc.grc, and
> rfnoc_duc.grc
>
>
> Which version of Ubuntu is the most stable running the RFNoC flowgraphs?
> 14.04, 15.04, or 16.04?
>
>
> I am using a UBX-160.
>
>
> I followed the appnote getting started with RFNoC:
>
> git clone --recursive -b rfnoc-devel https://github.com/
> EttusResearch/uhd.git
> <https://github.com/EttusResearch/uhd.git>
> GitHub - EttusResearch/uhd: The USRP? Hardware Driver Repository
> <https://github.com/EttusResearch/uhd.git>
> github.com
> uhd - The USRP? Hardware Driver Repository
>
> git clone --recursive -b master https://github.com/gnuradio/gnuradio.git
> <https://github.com/gnuradio/gnuradio.git>
> GitHub - gnuradio/gnuradio: GNU Radio
> <https://github.com/gnuradio/gnuradio.git>
> github.com
> gnuradio - GNU Radio
>
> git clone -b master https://github.com/EttusResearch/gr-ettus.git
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <(770)%20298-9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170622/980ff126/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 22 Jun 2017 21:12:05 +0000
From: "Hood, Christopher L." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310 transmit underflow when sampling rate is
low
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'm running a simple one pulse loopback transmit/receive and am running into
transmit underflows when the sampling rate is LOW. Specifically, for my short
30 us pulse, the underflow occurs when the sampling rate is 5 MHz or lower. I
ran the test at 10, 20, 25, 33.3, 50, 100, and 200 MHz with no issues at all.
The X310 is connected to the host over 10 gig Ethernet, and the tx stream send
command is set with metadata so start of burst=1, end of burst=1, has time=1,
and with the time spec well into the future wrt the device. The send command
returns without incident, and when the time spec elapses, the async message is
received, which indicates an underflow. Looking at the receive samples, the
underflow appears to occur at the beginning of the intended transmission,
because much of the intended waveform is being received.
Any direction into fixing this issue would be appreciated.
Thanks,
chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170622/e505e44b/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 22 Jun 2017 20:08:55 -0400
From: EJ Kreinar <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-modtool cores
Message-ID:
<CADRnH22K2OeQ1899xqOUg=rdjf9y3onhwkj9h76epxuwbu0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jason,
If you're using my forked edits for uhd-fpga, then the Makefile.OOT.inc can
be generated with the uhd_image_builder.py with multiple include folders
command line arguments. For example, here's the makefile output when I ran
"./uhd_image_builder.py fft window -I ~/prefix/rfnoc/src/rfnoc-ootexample
~/prefix/rfnoc/src/rfnoc-neuralnet"
##################################################
# Include OOT makefiles
##################################################
OOT_DIR = $(BASE_DIR)/../../../rfnoc-ootexample/rfnoc
include $(OOT_DIR)/Makefile.inc
OOT_DIR = $(BASE_DIR)/../../../rfnoc-neuralnet/rfnoc
include $(OOT_DIR)/Makefile.inc
I've also had luck hand-editing as needed. Hope this helps! Let me know if
you still run into issues
EJ
On Wed, Jun 21, 2017 at 9:45 AM, Jason Matusiak <
[email protected]> wrote:
> EJ, How did you add more than one repo to the line?
>
> ~Jason
>
>
> On 06/14/2017 08:43 PM, EJ Kreinar wrote:
>
> Yes, this is an admitted hack, I should say.
>
> The assignment to MY_OOT_DIR := OOT_DIR in the
> rfnoc-ootexample/rfnoc/Makefile.inc forces the evaluation of OOT_DIR
> immediately, and the OOT modules uses MY_OOT_DIR from then on, for example.
> I've tested this successfully with multiple different OOT repos.
>
> If you have a suggested improvement that's less hacky though, I'm
> definitely interested :)
>
> EJ
>
> On Wed, Jun 14, 2017 at 2:08 PM, Jason Matusiak <
> [email protected]> wrote:
>
>> EJ,
>> I am creating a new RFNoC repo and thought I would go through your write
>> up and see if I can find anything that we missed while you and I were
>> working offline. The first thing I wondered was, in the Makefile.OOT.inc,
>> can I have more than one OOT_DIR? I have one in there right now for my
>> current blocks, but I am not sure how to point to a different folder
>> without screwing your setup up.
>>
>> ~Jason
>>
>>
>> On 05/23/2017 10:04 PM, EJ Kreinar wrote:
>>
>> Hi Jason and others,
>>
>> As a follow up, I put together an rfnoc OOT repo that uses Makefiles to
>> build Vivado IP and HLS IP: https://github.com/ejk43/rfnoc-ootexample
>>
>> The simulations should run successfully when uhd-fpga is set up correctly
>> (see readme), and also should build the OOT noc_blocks into an FPGA image
>> using "make E310_RFNOC" etc etc.
>>
>> Hope this helps,
>> EJ
>>
>> On Fri, May 19, 2017 at 12:08 PM, EJ Kreinar <[email protected]> wrote:
>>
>>> Jason,
>>>
>>> Sure, I'd say just clone my fpga repo and apply the patch for now.
>>> Quick instructions:
>>>
>>> 1. In your uhd-fpga repo: `git remote add ejk
>>> https://github.com/ejk43/fpga.git` <https://github.com/ejk43/fpga.git>
>>> a. This now sets up a remote named "ejk" which points to my fork
>>> 2. Then: `git fetch ejk new_oot_includes`
>>> 3. Then you can either checkout this branch (if you have no other
>>> changes on your uhd-fpga repo), or cherry-pick the commits from the
>>> new_oot_includes branch.
>>>
>>>
>>> In lieu of an example OOT repo, here's how I set up my "rfnoc" folder
>>> structure in the OOT repo:
>>>
>>> rfnoc:
>>> + Makefile.inc
>>> + blocks
>>> + testbenches
>>> + fpga-src
>>> + Makefile.inc
>>>
>>> + noc_block_testblock.v
>>>
>>> + ip
>>> + Makefile.inc
>>> + my_ip
>>> + my_ip.xci
>>> + Makefile.inc
>>>
>>>
>>>
>>> Here's an example top-level Makefile.inc:
>>>
>>> RFNOC_MYTEST_DIR := $(OOT_DIR)
>>> include $(abspath $(RFNOC_MYTEST_DIR)/fpga-src/Makefile.inc)
>>> include $(abspath $(RFNOC_MYTEST_DIR)/ip/Makefile.inc)
>>>
>>>
>>>
>>> Then the fpga-src Makefile.inc:
>>>
>>> RFNOC_OOT_SRCS += $(addprefix $(RFNOC_MYTEST_DIR)/fpga-src/, \
>>> noc_block_testblock.v \
>>> )
>>>
>>>
>>>
>>> Then the IP Makefile.inc (modeled after the Makefile.inc in the
>>> uhd-fpga/usrp3/lib/ip:
>>>
>>> include $(RFNOC_MYTEST_DIR)/ip/my_ip/Makefile.inc
>>>
>>> LIB_MYTEST_IP_XCI_SRCS = \
>>> $(LIB_IP_MY_IP_SRCS)
>>>
>>> LIB_MYTEST_IP_SYNTH_OUTPUTS = \
>>> $(LIB_IP_MY_IP_OUTS)
>>>
>>> LIB_IP_XCI_SRCS += $(LIB_MYTEST_IP_XCI_SRCS)
>>>
>>>
>>>
>>> And finally, the Makefile.inc inside the my_ip directory (modeled after
>>> the lib/ip/xxx Makefile.inc):
>>>
>>> include $(TOOLS_DIR)/make/viv_ip_builder.mak
>>>
>>> LIB_IP_MY_IP_SRCS = $(IP_BUILD_DIR)/my_ip/my_ip.xci
>>>
>>> LIB_IP_MY_IP_OUTS = $(addprefix $(IP_BUILD_DIR)/my_ip/, \
>>> my_ip.xci.out \
>>> synth/my_ip.vhd \
>>> )
>>>
>>> $(LIB_IP_MY_IP_SRCS) $(LIB_IP_MY_IP_OUTS) : $(LIB_IP_DIR)/my_ip/my_ip
>>> .xci
>>> $(call BUILD_VIVADO_IP,my_ip,$(ARCH),$(PART_ID),$(LIB_IP_DIR),$(IP_
>>> BUILD_DIR),0)
>>>
>>>
>>>
>>> It's also possible to rejigger the testbench makefiles to build the OOT
>>> IP for your testbench.
>>>
>>> Again, I should pull this into an example OOT repo sometime soon, which
>>> would make it a bit easier to have an example. Let me know if you hit any
>>> problems.
>>>
>>> EJ
>>>
>>> On Fri, May 19, 2017 at 8:38 AM, Jason Matusiak <
>>> [email protected]> wrote:
>>>
>>>> EJ, that looks exactly like what I need to do. Is there a way for me
>>>> to patch in your changes so I can try to use them while we wait for Ettus
>>>> to (dis)approve your PR?
>>>>
>>>> Thanks!
>>>> ~Jason
>>>>
>>>>
>>>>
>>>> On 05/18/2017 04:11 PM, EJ Kreinar wrote:
>>>>
>>>> Hi Jason,
>>>>
>>>> I currently have a PR in to the fpga repo (
>>>> https://github.com/EttusResearch/fpga/pull/12) that adds support for
>>>> linking Makefile.inc files in OOT repos. Your OOT Makefile can then build
>>>> the Xilinx IP and append it to your build as needed. I've been using this
>>>> approach for some time now with success for both Xilinx IP and HLS designs.
>>>>
>>>> I have an action to provide a sample "dummy" OOT repo with the correct
>>>> Makefiles-- but I havent gotten to it yet, unfortunately-- Was waiting for
>>>> confirmation if this approach will be supported in-tree in the future. I
>>>> could put something together soon though if this would help.
>>>>
>>>> I'd also be interested in other good solutions, if anyone has an
>>>> alternate approach :)
>>>>
>>>> EJ
>>>>
>>>> On Thu, May 18, 2017 at 2:22 PM, Jason Matusiak via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> I wanted to create an RFNoC block that utilized some Xilinx cores.
>>>>> Where do I need to put these cores in the rfnoc-modtool project created
>>>>> directory structure, and how do I go about tying that into the Vivado GUI
>>>>> so I can build them up (just use the GUI=1 CL argument and do the save-as
>>>>> project approach?)?
>>>>>
>>>>> _______________________________________________
>>>>> 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/20170622/4830ca48/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 22 Jun 2017 17:09:16 -0700
From: Jacob Knoles <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Multiple timed bursts on X300
Message-ID:
<ca+z4yfgsvwar-8crk8ak40xs0yrzu4quzf68mx6ldq+gxe2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I am trying to transmit a sequence of bursts using a X300 being programmed
with the UHD C++ api.
At this time I am successfully transmitting the first burst but all
subsequent bursts result in a failure.
After each burst transmission I check the tx stream for async messages,
looking for the ack, after the first burst returns successfully I get no
messages back from any other burst, resulting in a tx failure.
I have followed the tx_bursts example provided with UHD but it seems to me
like send is not blocking the thread, as it is described to do. I have a
loop that checks the device time, waiting until the known end of the burst
period before advancing to the next burst and without this loop the code
executes everything immediately and I see no transmissions at all.
I have a queue of burst information objects that I iterate through with the
following processing:
Set the metadata with a known timespec to transmit.
transmit the signal
Wait until the signal should have finished
transmit an end of burst packet.
pop the queue and repeat.
I am not sure what is going wrong here?
Thanks for any help.
-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170622/4da334e4/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 23 Jun 2017 11:34:29 +1000
From: Walter Maguire <[email protected]>
To: [email protected]
Subject: [USRP-users] Complex FFT display of Frequency offset.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all.
We were performing some basic Receiver tests on the E310 in RFNoC mode.
A snapshot of my simple grc and associated outputs are shown in the
attached screen shots.
The RX frequency of the E310 is set to 836.5MHz. The sample rate is set
to 1MHz. The center frequency on the QT Frequency Sink is set to 836.5
MHz. If I apply a carrier only frequency at 836.5MHz then it appears
as expected in the center of the frequency display. However, if I
change the frequency of the carrier by +100KHz to 836.6MHz I see the
carrier displayed at +300kHz offset or 836.8MHz. This does not seem to
be correct. We would expect it to be at 836.6MHz I might expect a
halving or doubling due to complex I/Q signals being 1/2 the BW. I
don't understand why we see times 3 for the offset.
I tested the QTGUI display using a complex sine wave and it works as
expected that is at 0Hz it is in the center and the frequency displayed
on the FFT track the frequency of the complex sine wave. Therefore I
think the issue (or understanding) is in the E310.
I would be grateful if anyone could shed some light on our observations.
Regards
Walter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: complexFFT_836.6MHz.png
Type: image/png
Size: 236331 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/f15677a0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: complexFFT_836.5MHz.png
Type: image/png
Size: 228429 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/f15677a0/attachment-0003.png>
------------------------------
Message: 6
Date: Fri, 23 Jun 2017 11:46:49 +1000
From: Walter Maguire <[email protected]>
To: [email protected]
Subject: [USRP-users] Complex FFT Display Follow-up
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi All,
I reduced the stream to stream component to one output and then
connected directly to the QT GUI display. It now works as expected.
Regards
Walter
------------------------------
Message: 7
Date: Fri, 23 Jun 2017 11:31:00 +0000
From: carry chen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] start/stop usrp perfect
Message-ID:
<sixpr06mb09053f640569b86390d345dcdd...@sixpr06mb0905.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
hi,list,
how can I stop usrp perfect?
if I want to start and stop usrp period quick(for examble do rssi scan with
diffrent freq),how to do that?
I find that if start and stop usrp frequently,I get some usb error.
I use b205mini.
Thanks.
Best Regards,
Carry
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/fc720f55/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 23 Jun 2017 09:00:59 -0400
From: olivani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file bandwidth does not take
effect
Message-ID:
<cabq0viwgvwcnutsya8kxfdycpgrq-2bfxe5ytjcf7+iwoen...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus ,
I tried several experiments by varying the bandwidth from 2 to 10 MHz. I am
able to see the roll off at specified points but I am not sure why the data
collected is equal to the sample rate.. I would like to know if this is
replicable or am I making some mistakes in my settings.
For my application I need to collect data at bandwidth of 20 MHz and at
sampling rate 25 Msps . Please let me know if I am missing something .
Eventually I am not going to collect data to the file instead do some post
processing with the received data . The data collection to file is for
validation purpose. I have the custom FPGA build to do the post processing
with the streamed data.
Could you please throw some light on what is happening and where I might be
wrong.
Thanks and Regards,
OIivani
Thanks and Regards,
Olivani Subbukutty
571-331-2481
On Wed, Jun 21, 2017 at 9:23 AM, olivani <[email protected]> wrote:
> Hi Marcus,
>
> I tried with master clock at 40 Msps but I am still able to see the tone.
> Please have a look at the attached document.
> The incoming signal is -27.3 dbm .
>
> Thanks and Regards,
> Olivani Subbukutty
> 571-331-2481 <(571)%20331-2481>
>
> On Tue, Jun 20, 2017 at 10:56 PM, Marcus D. Leech <[email protected]>
> wrote:
>
>> On 06/20/2017 04:33 PM, olivani wrote:
>>
>> Hi Marcus ,
>>
>> Please find the attached document along with this mail.
>>
>> Thanks and Regards,
>> Olivani Subbukutty
>> 571-331-2481 <(571)%20331-2481>
>>
>> Could you try running the master clock at 40Msps? With
>> master==sample-rate, there's not much room to do any digital fitlering.
>>
>> Also, what levels are the signals entering the device?
>>
>>
>>
>> On Tue, Jun 20, 2017 at 3:37 PM, Marcus D. Leech <[email protected]>
>> wrote:
>>
>>> On 06/20/2017 03:32 PM, olivani wrote:
>>>
>>>>
>>>>
>>>> I did get that message and it says the bandwidth is set . But once you
>>>> collect the data and plot it out for example say you have a tone on 12
>>>> MHz and collect data of 10 MHz bandwidth with center 5 MHz freq and set
>>>> the clock rate and sampling rate to 16 Msps , when I collect the data , I
>>>> am not supposed to see a tone as I assumed the data would be collected from
>>>> 0-10 MHz . But it seems that the data bandwidth collected is equal to the
>>>> sampling rate and so in the upper edge from 5 to 13 MHz I am able to see
>>>> the tone. I tried in different devices and using 3.92 release code. We
>>>> did a fpga probe and also noticed the same scenario. So I am wondering does
>>>> the sample rate option overrides the analog filter BW option . Does the bw
>>>> option has any effect. It would be great if somebody could help me out with
>>>> this.
>>>>
>>>>
>>>> Well, it's complex-baseband, so the useful samples go from -bw/2 to
>>> +bw/2
>>>
>>> Could you perhaps produce an FFT plot to show the artifacts you think
>>> shouldn't be there?
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/bb697211/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 23 Jun 2017 15:40:29 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file bandwidth does not take
effect
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Olivani,
had to take your document apart (convert the .docx to a zip file, unzip,
extract the images and text) manually; for some reason, my libreOffice
crashes with your word document. So, I'd like to verify this is the same
content that you've sent, and I'm not missing anything (if it is, please
just send future things simply as Email content ? it's not really
necessary to fire up word for this). Please find my comments below the
document's (approximate) contents:
------------------------------------------------------------------------
Output log
./rx_samples_to_file --file /dev/test_5bw_20msps_3 --subdev A:B
--args="type=e3x0,master_clock_rate=40e6" --bw 5e6 --freq 110e6 --gain 10
--rate 20e6 --duration 1 --stats
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
Creating the usrp device with: type=e3x0,master_clock_rate=40e6...
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga_sg3.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting time source to internal
-- Asking for clock rate 40 MHz
-- Actually got clock rate 40 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
Using Device: Single USRP:
Device: E-Series Device
Mboard 0: E3XX
RX Channel: 0
RX DSP: 1
RX Dboard: A
RX Subdev: FE-RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX2
TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: FE-TX1
Setting RX Rate: 20.000000 Msps...
Actual RX Rate: 20.000000 Msps...
Setting RX Freq: 110.000000 MHz...
Actual RX Freq: 110.000000 MHz...
Setting RX Gain: 10.000000 dB...
Actual RX Gain: 10.000000 dB...
Setting RX Bandwidth: 5.000000 MHz...
Actual RX Bandwidth: 5.000000 MHz...
Waiting for "lo_locked": ++++++++++ locked.
Press Ctrl + C to stop streaming...
Received 20010000 samples in 1.000178 seconds
20.006439 Msps
Done!
PSD
------------------------------------------------------------------------
So, we can luckily see the bandwidth setting having *some* effect; see
how things roll off at 2.5 MHz. The attenuation actually only seems to
be 6 dB, which is less than what I'd expect, but it's still there:
Annotated PSD
Now, my suspicion is that you might be driving the input RX amplifier
into nonlinearity, and then, all filtering after that amplifier is kind
of moot, and you might be getting intermodulation of noise floor from
anywhere and your LO. How much power are you inserting into the E310?
What's the /exact/ formula of your FFT plot? Is it possible we're
missing the top of the spike, it being to narrow to actually fill one
pixel width in your image? I'm very concerned because the spike's
amplitude seems to be larger than 0dB, which is what I'd normalize the
maximum mathematically possible signal to; so, it'd be important to know
which kind of DFT formula (normalization) your FFT uses, and how your
plotting deals with the fact that your DFT seems to be longer than 205
elements, but your plot is only 205 pixels wide.
Best regards,
Marcus
On 23.06.2017 15:00, olivani via USRP-users wrote:
> Hi Marcus ,
>
> I tried several experiments by varying the bandwidth from 2 to 10 MHz.
> I am able to see the roll off at specified points but I am not sure
> why the data collected is equal to the sample rate.. I would like to
> know if this is replicable or am I making some mistakes in my settings.
> For my application I need to collect data at bandwidth of 20 MHz and
> at sampling rate 25 Msps . Please let me know if I am missing
> something . Eventually I am not going to collect data to the file
> instead do some post processing with the received data . The data
> collection to file is for validation purpose. I have the custom FPGA
> build to do the post processing with the streamed data.
>
> Could you please throw some light on what is happening and where I
> might be wrong.
>
> Thanks and Regards,
> OIivani
>
> Thanks and Regards,
> Olivani Subbukutty
> 571-331-2481
>
> On Wed, Jun 21, 2017 at 9:23 AM, olivani <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Marcus,
>
> I tried with master clock at 40 Msps but I am still able to see
> the tone. Please have a look at the attached document.
> The incoming signal is -27.3 dbm .
>
> Thanks and Regards,
> Olivani Subbukutty
> 571-331-2481 <tel:%28571%29%20331-2481>
>
> On Tue, Jun 20, 2017 at 10:56 PM, Marcus D. Leech
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 06/20/2017 04:33 PM, olivani wrote:
>> Hi Marcus ,
>>
>> Please find the attached document along with this mail.
>>
>> Thanks and Regards,
>> Olivani Subbukutty
>> 571-331-2481 <tel:%28571%29%20331-2481>
> Could you try running the master clock at 40Msps? With
> master==sample-rate, there's not much room to do any digital
> fitlering.
>
> Also, what levels are the signals entering the device?
>
>
>>
>> On Tue, Jun 20, 2017 at 3:37 PM, Marcus D. Leech
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> On 06/20/2017 03:32 PM, olivani wrote:
>>
>>
>>
>> I did get that message and it says the bandwidth is
>> set . But once you collect the data and plot it out
>> for example say you have a tone on 12 MHz and
>> collect data of 10 MHz bandwidth with center 5 MHz
>> freq and set the clock rate and sampling rate to 16
>> Msps , when I collect the data , I am not supposed to
>> see a tone as I assumed the data would be collected
>> from 0-10 MHz . But it seems that the data bandwidth
>> collected is equal to the sampling rate and so in the
>> upper edge from 5 to 13 MHz I am able to see the
>> tone. I tried in different devices and using 3.92
>> release code. We did a fpga probe and also noticed
>> the same scenario. So I am wondering does the sample
>> rate option overrides the analog filter BW option .
>> Does the bw option has any effect. It would be great
>> if somebody could help me out with this.
>>
>>
>> Well, it's complex-baseband, so the useful samples go
>> from -bw/2 to +bw/2
>>
>> Could you perhaps produce an FFT plot to show the
>> artifacts you think shouldn't be there?
>>
>>
>>
>
>
>
>
>
> _______________________________________________
> 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/20170623/9d0d6a06/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PSD.png
Type: image/png
Size: 10700 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/9d0d6a06/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PSD_annotated.png
Type: image/png
Size: 3455 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/9d0d6a06/attachment-0003.png>
------------------------------
Message: 10
Date: Fri, 23 Jun 2017 10:42:57 -0400
From: Jason Matusiak <[email protected]>
To: Philip Balister <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] weird E310 libboost update problem
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
OK, that makes sense, thanks Philip. All is running fine now, thanks!!
On 06/22/2017 10:21 AM, Philip Balister wrote:
> On 06/22/2017 09:50 AM, Jason Matusiak via USRP-users wrote:
>> Philip, How would the directions go now (I am originally following the
>> ones from the Ettus website)? I don't see somewhere in my prefix to
>> replace the oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh with
>> the one that was in the jethro-test folder.
>>
>> So I am guessing that I need to download it, and then run it, and let it
>> install to the default /usr/local/oecore-x86_64?
> Ah, here is the answer to your question. Don't use the default install
> path :)
>
> I have (on one machine):
>
> [balister@mini ~]$ ls sdks/
> master-032016 release-4
>
> So I made a directory "sdks" in my home directory and and install the
> sdks there. This way I can easily access multiple sdks, dependsing on
> what I am using and/or testing.
>
> Philip
>
>
>> If want to bounce between two different images (say a new one and the
>> one we've been fielding), is there a way two have two of these installed
>> at the same time? Or do I just need to keep overwriting things?
>>
>> ~Jason
>>
>>
>> On 06/21/2017 03:28 PM, Philip Balister wrote:
>>> On 06/21/2017 02:55 PM, Jason Matusiak via USRP-users wrote:
>>>> I took an SD card and put a brand new E310 load on it:
>>>> e3xx_images/beta/jethro-test/sdimage-gnuradio-demo.direct.xz.
>>> Also use the sdk from this directory, not the older one.
>>>
>>> Philip
>>>
>>>> That went fine and it booted normally. I then went into my e3xx prefix
>>>> and made a build-arm directory in uhd/host. I then cd-ed into it and
>>>> ran:
>>>> cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
>>>> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON ..
>>>>
>>>> then I ran: make -j4
>>>>
>>>> After that, I ran mkdir ~/E310_remote && sshfs -o allow_root
>>>> [email protected]:/ /home/jmat/E310_remote
>>>>
>>>> then: make install
>>>>
>>>> This installs everything across the network to the E310 unit. I then
>>>> rebooted the E310 to make sure all was OK and it booted up fine. Next I
>>>> ran a uhd_usrp_probe fully expecting it to through a compatibility
>>>> mismatch error since the FPGA bitfile wasn't updated yet, but instead I
>>>> got this error:
>>>> # uhd_usrp_probe
>>>> uhd_usrp_probe: error while loading shared libraries:
>>>> libboost_program_options.so.1.57.0: cannot open shared object file: No
>>>> such file or directory
>>>>
>>>> When I go look in /usr/lib, I see the following:
>>>> lrwxrwxrwx 1 root root 34 Apr 4 18:37
>>>> ./usr/lib/libboost_program_options.so ->
>>>> libboost_program_options.so.1.58.0
>>>> -rwxr-xr-x 1 root root 385360 Apr 4 18:37
>>>> ./usr/lib/libboost_program_options.so.1.58.0
>>>>
>>>> So it looks to me as if the uhd_usrp_probe was built again libboost
>>>> 1.57, but the image is running at 1.58. What should I do to get past
>>>> this?
>>>>
>>>> _______________________________________________
>>>> 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
>>
------------------------------
Message: 11
Date: Fri, 23 Jun 2017 11:13:27 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 gnuradio not showing RFNoC blocks
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
My fresh E310 seems to be running fine and a uhd_usrp_probe shows me the
default RFNoC blocks, so I know the bitfile and UHD is good.
When I run GRC on there are no RFNoC blocks or the device3 block, is
there a step I missed (I don't usually have all these issues with my
host machine and my X310)?
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 82, Issue 22
******************************************
