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: Custom Board (Neel Pandeya)
2. X310 runs rfnoc-devel FPGA code but will not run
rfnoc-radio-redo FPGA code (Swanson, Craig)
3. Re: X310 runs rfnoc-devel FPGA code but will not run
rfnoc-radio-redo FPGA code (Jonathon Pendlum)
4. Re: UBX Tx-to-Rx interference, Performance and Power-Save
modes (Martin Braun)
5. Re: rfnoc-radio-redo and RX path (Martin Braun)
6. Re: X310 runs rfnoc-devel FPGA code but will not run
rfnoc-radio-redo FPGA code (Swanson, Craig)
7. Re: X310 runs rfnoc-devel FPGA code but will not run
rfnoc-radio-redo FPGA code (Martin Braun)
8. Re: X310 runs rfnoc-devel FPGA code but will not run
rfnoc-radio-redo FPGA code (Swanson, Craig)
9. Re: rfnoc-radio-redo DDC block test (Jonathon Pendlum)
10. Re: rfnoc-radio-redo and RX path (Nick Foster)
11. Re: Error when running noc_block_fir_filter_tb in Modelsim in
rfnoc-radio-redo branch : cannot open wave.do file (Jonathon Pendlum)
12. Re: rfnoc-radio-redo DDC block test (Nick Foster)
13. Re: RFNoC on the E310 (Jonathon Pendlum)
14. Re: UBX Tx-to-Rx interference, Performance and Power-Save
modes (Michael West)
15. Re: RFNoC on the E310 (Martin Braun)
16. Re: RFNoC on the E310 (Martin Braun)
17. Re: Custom Board (Joshua Monson)
18. Effective a length of VERT2450 antenna and its impact on
receiving signal. (Jeon)
19. Reg : Invoking FPGA functions thru C program (Sumit Kumar)
20. Re: Effective a length of VERT2450 antenna and its impact on
receiving signal. (Steven Knudsen)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Jun 2016 09:17:20 -0700
From: Neel Pandeya <[email protected]>
To: Joshua Monson <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Custom Board
Message-ID:
<cacaxmv9gdyodtwacxv4vs4-wqheezc1qhdtbbgmexucsdvj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Josh:
We basically don't use IP integrator for any of our Vivado development, and
so we're not really familiar with how it works. I know that there are no
auto-generated headers for our stuff, so there is nothing that you could
export to the Xilinx SDK.
Could you describe in more detail exactly what you're trying to do?
Thanks.
--Neel Pandeya
On 13 June 2016 at 08:12, Joshua Monson via USRP-users <
[email protected]> wrote:
>
>
>
>
> *From:* Joshua Monson [mailto:[email protected]]
> *Sent:* Thursday, June 9, 2016 3:17 PM
> *To:* 'Matt Ettus' <[email protected]>
> *Subject:* RE: [USRP-users] Custom Board
>
>
>
> Matt,
>
>
>
> I agree whole-heartedly with you and that is what I attempted to do
> initially. Unfortunately, I ran into a roadblock in which Vivado would not
> export the PS configuration and address mappings to the SDK unless the Zynq
> processing system was declared in a top-level IP integrator design. How did
> you guys get around this Vivado restriction? It seems to me that even
> though you?re using Linux you would still need that Vivado to generate the
> device tree source and PS configuration files.
>
>
>
> Thanks,
>
>
>
> Josh
>
>
>
>
>
> *From:* Matt Ettus [mailto:[email protected] <[email protected]>]
> *Sent:* Thursday, June 9, 2016 2:39 PM
> *To:* Joshua Monson <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Custom Board
>
>
>
>
>
> Joshua,
>
>
>
> While you are welcome to try this, you have chosen an extremely difficult
> path. There is a lot of complexity in a board like this. You would be far
> better off if you started with our top level design an removed the parts
> you don't want, rather than try to recreate everything in a vacuum.
> Otherwise, you'll need to look at the schematics to make sure every pin is
> driven properly.
>
>
>
> Matt
>
>
>
>
>
> On Thu, Jun 9, 2016 at 8:43 AM, Joshua Monson via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
>
>
> We?re developing a custom bare-metal FPGA design for the USRP E310. The
> plan is to have the FPGA configured with this design via an SDCard image
> when the board powers up. To begin our development we?d like to start with
> minimal FPGA design that can bring the board up safely without damaging the
> other components. To this end I?ve created an initial design in Xilinx
> Vivado by importing the PS configurations (presets) from the E3XX_idle
> design in UHD. On the FPGA side (PL), I?ve imported and integrated the AXI
> PMU and constant logic values connected to external I/O (also from
> E3XX_idle). I?ve also imported the constraint files from E3XX_idle to
> ensure the I/O voltage levels are configured properly.
>
>
>
> Is there anything else that I need to do to ensure that the board and FPGA
> powers on properly?
>
>
>
> Thanks,
>
>
>
> Josh
>
>
> _______________________________________________
> 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/20160613/bfd523ca/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 13 Jun 2016 16:44:50 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus M?ller
<[email protected]>, "[email protected]"
<[email protected]>
Subject: [USRP-users] X310 runs rfnoc-devel FPGA code but will not run
rfnoc-radio-redo FPGA code
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
After loading the code on the X310 and running uhd_usrp_probe --init-only, I
get the following error:
Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to lock?
I am assuming the issue is that the image running on the X310 is not the
latest? I knew how to get around this problem with the E310, but I am not sure
how to solve the problem with the X310.
Craig
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
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/20160613/8447bd01/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 13 Jun 2016 11:50:26 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus M?ller
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] X310 runs rfnoc-devel FPGA code but will not
run rfnoc-radio-redo FPGA code
Message-ID:
<cagdo0uqlkxkhofqs5uwmhafretesfqjatnvnr4hcx3tgc9d...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Craig,
The two code bases have a large number of changes, so you need to run a
rfnoc-radio-redo FPGA image with the rfnoc-radio-redo UHD / gr-ettus code.
Jonathon
On Mon, Jun 13, 2016 at 11:44 AM, Swanson, Craig <
[email protected]> wrote:
> ?Jonathon,
>
> After loading the code on the X310 and running uhd_usrp_probe --init-only,
> I get the following error:
>
> Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to lock?
>
>
> I am assuming the issue is that the image running on the X310 is not the
> latest? I knew how to get around this problem with the E310, but I am not
> sure how to solve the problem with the X310.
>
>
> Craig
>
>
> *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.298.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/20160613/d152d332/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 13 Jun 2016 10:00:14 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UBX Tx-to-Rx interference, Performance and
Power-Save modes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Hanwen,
all the fixes we have cooked up recently are on maint (and master). Are
you still having issues?
Cheers,
Martin
On 06/12/2016 12:04 PM, hanwen via USRP-users wrote:
> Hi Michael,
>
> Any new progress in improving UBX support in UHD? Thanks.
>
> Br, Hanwen
>
> 2016-05-26 12:50 GMT+02:00 hanwen <[email protected]
> <mailto:[email protected]>>:
>
> Hi Michael,
>
> No difference with this patch. The transmitted signal is too weak,
> confirmed by an additional spectrum analyzer as receiver.
> I noticed that in the patch, many "FORCEON" are set to 0 in the
> performance, could it be the reason that the Tx power is so low?
>
> Br, Hanwen
>
> 2016-05-24 22:14 GMT+02:00 Michael West <[email protected]
> <mailto:[email protected]>>:
>
> Hi Hanwen,
>
> Thanks for the feedback. Can you remove the previous patches
> and apply the new one attached? It is slightly different than
> the previous one. I tested and had no issues with it.
>
> Regards,
> Michael
>
> On Tue, May 24, 2016 at 12:48 PM, hanwen
> <[email protected] <mailto:[email protected]>> wrote:
>
> HI Michael,
>
> I tested your new patch today. At the Rx side, yes, the
> noise floor low and doesn't affected by Tx. BUT, the Tx
> power is also low and it looks like the same as with the
> powersave mode in my TDMA/TDD system configuration. Thanks.
>
> Br, Hanwen
>
> 2016-05-24 0:43 GMT+02:00 Michael West
> <[email protected] <mailto:[email protected]>>:
>
> Hi Hanwen,
>
> We see the same results. Further investigation into the
> issue has yielded the attached updated patch. We are
> still working on the issue, but please try the patch and
> let me know if it improves the noise figure for you. It
> should work well in performance or powersave mode.
>
> Regards,
> Michael
>
> On Mon, May 23, 2016 at 1:35 PM, hanwen
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Michael,
>
> Thanks for the patch. I tried today and it fixed the
> issue that the Rx noise floor raises along with the
> increasing Tx gain.
> But it seems in the default performance mode, the
> noise floor is higher than in the powersave mode and
> the actual noise figure is also poorer. I'll do some
> further test tomorrow and try to tweak the CPLD
> field options in db_ubx.cpp.
>
> Br, Hanwen
>
> 2016-05-19 19:47 GMT+02:00 Michael West
> <[email protected]
> <mailto:[email protected]>>:
>
> Hi Hanwen,
>
> There is an issue for UBX in TDD mode of which
> we are aware and in the process of fixing. In
> the meantime, apply the attached patch and use
> the default (performance) power mode and let me
> know if it helps.
>
> Regards,
> Michael
>
> On Wed, May 18, 2016 at 9:03 PM, hanwen
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Dear USRP users and experts,
>
>
>
> Instructed by Michael
> in:
> https://www.mail-archive.com/[email protected]/msg01766.html
>
> I tried the switching between powersave and
> performance mode for the new UBX and did
> some further test.
>
>
>
> Basic config: 11.42MS/s, Carrier: 2.6GHz,
> TDMA mode with 1ms time slot and one device
> switches between Tx and Rx every 1ms; UHD
> and firmware are the fresh 3.9.4 release.
>
>
>
> * *
>
>
>
> *Power Save*
>
>
>
> *Performance*
>
> *Tx*
>
>
>
> The transmitted signal is very weak no
> matter what Tx gain is chosen
>
>
>
> The transmission is fine, but the maximum Tx
> power is 2~3dB lower than SBX
>
> The device is getting very hot
>
> *Rx*
>
>
>
> The noise floor not affected by Tx
>
>
>
> Noise floor rising up by c.a. 7dB by setting
> to higher Tx gain (>21.5), EVEN WHEN no
> transmission in Tx slot
>
>
>
> In the attachment you could see some
> screenshots:
>
> ? Tg_1.5~31.5.png: showing the
> rising Rx noise floor in the default
> Performance mode
>
> ? Cst_performance/powersave.png:
> showing in the Powersave mode: the
> constellation demodulated at another device
> is very poor due to weak transmit power.
>
>
>
> For both powersave and performance mode we
> observed unacceptable problems for our
> system, but using the older SBX-40 and SBX
> 120 boards we didn?t observe these problems.
>
>
>
> Bests, Hanwen
>
>
>
> ???? 7???? 8???? 9???? 10?
> ??? 11???? 12
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Mon, 13 Jun 2016 10:04:10 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] rfnoc-radio-redo and RX path
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Nick,
is this dboard-dependent? Does a BasicRX work? And does the side matter?
M
On 06/09/2016 11:24 AM, Nick Foster via USRP-users wrote:
> Hi guys,
>
> Having some trouble on rfnoc-radio-redo trying to simply receive
> something with a WBX.
>
> FG just looks like this:
>
> pasted1
> ? // //
>
>
> Only receiving very low-level noise on the output. No indication of
> signal (flat spectrum, faint DC offset), though there is CW being put
> into the front end. The output appears independent of both gain and
> frequency setting in the RFNoC Radio block. I don't even care about the
> integrity of the signal -- obviously Keep 1 in N isn't going to do me
> any favors there. Just trying to prove I'm hearing anything at all with
> this simple flowgraph.
>
> Any hints?
> --n
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Mon, 13 Jun 2016 17:05:24 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 runs rfnoc-devel FPGA code but will not
run rfnoc-radio-redo FPGA code
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
Does running uhd_usrp_probe --init-only rely on gr-ettus? I guess I didn't
realize that until now.
I will update as you have recommended.
Craig
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
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum <[email protected]>
Sent: Monday, June 13, 2016 12:50 PM
To: Swanson, Craig
Cc: Martin Braun; Marcus M?ller; [email protected]
Subject: Re: X310 runs rfnoc-devel FPGA code but will not run rfnoc-radio-redo
FPGA code
Craig,
The two code bases have a large number of changes, so you need to run a
rfnoc-radio-redo FPGA image with the rfnoc-radio-redo UHD / gr-ettus code.
Jonathon
On Mon, Jun 13, 2016 at 11:44 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
?Jonathon,
After loading the code on the X310 and running uhd_usrp_probe --init-only, I
get the following error:
Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to lock?
I am assuming the issue is that the image running on the X310 is not the
latest? I knew how to get around this problem with the E310, but I am not sure
how to solve the problem with the X310.
Craig
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<tel:770.298.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/20160613/48b24d33/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 13 Jun 2016 10:23:51 -0700
From: Martin Braun <[email protected]>
To: "Swanson, Craig" <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 runs rfnoc-devel FPGA code but will not
run rfnoc-radio-redo FPGA code
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
No, it doesn't. Jonathon was referring to the UHD repository.
M
On 06/13/2016 10:05 AM, Swanson, Craig via USRP-users wrote:
> ?Jonathon,
>
> Does running uhd_usrp_probe --init-only rely on gr-ettus? I guess I
> didn't realize that until now.
>
> I will update as you have recommended.
>
>
> Craig
>
>
> *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/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> ------------------------------------------------------------------------
> *From:* Jonathon Pendlum <[email protected]>
> *Sent:* Monday, June 13, 2016 12:50 PM
> *To:* Swanson, Craig
> *Cc:* Martin Braun; Marcus M?ller; [email protected]
> *Subject:* Re: X310 runs rfnoc-devel FPGA code but will not run
> rfnoc-radio-redo FPGA code
>
> Craig,
>
> The two code bases have a large number of changes, so you need to run a
> rfnoc-radio-redo FPGA image with the rfnoc-radio-redo UHD / gr-ettus code.
>
>
>
> Jonathon
>
> On Mon, Jun 13, 2016 at 11:44 AM, Swanson, Craig
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> ?Jonathon,
>
> After loading the code on the X310 and running uhd_usrp_probe
> --init-only, I get the following error:
>
> Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to lock?
>
>
> I am assuming the issue is that the image running on the X310 is not
> the latest? I knew how to get around this problem with the E310,
> but I am not sure how to solve the problem with the X310.
>
>
> Craig
>
>
> *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 <tel:770.298.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>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Mon, 13 Jun 2016 17:36:20 +0000
From: "Swanson, Craig" <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>,
"Jonathon Pendlum" <[email protected]>, Marcus M?ller
<[email protected]>
Subject: Re: [USRP-users] X310 runs rfnoc-devel FPGA code but will not
run rfnoc-radio-redo FPGA code
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Martin,
Would it be okay if you enlighten me a little about how the process works with
the X310 comparted to the E310 when creating a new noc_block?
E310:
- I ran into the same problem of rfnoc-devel running RFNOC but not
rfnoc-radio-redo. The solution was to get the latest image from Ettus and put
it on the SD card, then recompile everything on my pc, then cross compile what
was on my PC with the E310.
- If I created a new noc_block such as noc_block_Receiver, I would give it a
new NOC ID. Then I would create a new XML file in gr-ettus. This would enable
me to see it as a block in gnuradio. But I also had to create a new XML file
to move over to the E310 in order for uhd_usrp_probe to recognize my new
noc_block_Receiver. So there were a total of two XML files I had to create
when I created noc_block_Receiver.
X310:
- What is the solution for why noc_block_moving_avg created in rfnoc-radio-redo
fails but not rfnoc-devel when I run uhd_usrp_probe --init-only?
- If I create a new noc_block_Receiver, I understand the first step which is to
put a new .XML file in gr-ettus. But where do I put the .XML file so the X310
recognizes it when I run uhd_usrp_probe? With the E310, I would move the XML
file over to the directory where uhd_usrp_probe is looking for it.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu
-----Original Message-----
From: Martin Braun [mailto:[email protected]]
Sent: Monday, June 13, 2016 1:24 PM
To: Swanson, Craig <[email protected]>; Jonathon Pendlum
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] X310 runs rfnoc-devel FPGA code but will not run
rfnoc-radio-redo FPGA code
No, it doesn't. Jonathon was referring to the UHD repository.
M
On 06/13/2016 10:05 AM, Swanson, Craig via USRP-users wrote:
> ?Jonathon,
>
> Does running uhd_usrp_probe --init-only rely on gr-ettus? I guess I
> didn't realize that until now.
>
> I will update as you have recommended.
>
>
> Craig
>
>
> *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/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf
> 0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
> ----------------------------------------------------------------------
> --
> *From:* Jonathon Pendlum <[email protected]>
> *Sent:* Monday, June 13, 2016 12:50 PM
> *To:* Swanson, Craig
> *Cc:* Martin Braun; Marcus M?ller; [email protected]
> *Subject:* Re: X310 runs rfnoc-devel FPGA code but will not run
> rfnoc-radio-redo FPGA code
>
> Craig,
>
> The two code bases have a large number of changes, so you need to run
> a rfnoc-radio-redo FPGA image with the rfnoc-radio-redo UHD / gr-ettus code.
>
>
>
> Jonathon
>
> On Mon, Jun 13, 2016 at 11:44 AM, Swanson, Craig
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> ?Jonathon,
>
> After loading the code on the X310 and running uhd_usrp_probe
> --init-only, I get the following error:
>
> Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to
> lock?
>
>
> I am assuming the issue is that the image running on the X310 is not
> the latest? I knew how to get around this problem with the E310,
> but I am not sure how to solve the problem with the X310.
>
>
> Craig
>
>
> *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 <tel:770.298.9156>/
> http://www.gtri.gatech.edu
>
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf
> 0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 9
Date: Mon, 13 Jun 2016 12:36:23 -0500
From: Jonathon Pendlum <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-radio-redo DDC block test
Message-ID:
<cagdo0usrrm-c5wqcy7l80uys1cvwzuysp4dqtxgaolusy8m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This is a new block and still not officially "released," though it should
work. What block settings are you using, just the default ones in the GRC
files? Are you using 10GigE or 1GigE? Was this the first run or a
subsequent run?
Jonathon
On Thu, Jun 9, 2016 at 10:06 PM, Nick Foster via USRP-users <
[email protected]> wrote:
> Trying to get the gr-ettus/examples/rfnoc_ddc.grc example working, and
> getting the following:
>
> -- [RFNOC] ------- Block Setup -----------
> -- SEND (SID: 00:1f>02:a0)...Setting up NoC-Shell Control for port #0
> (SID: 00:1f>02:a0)...OK
> -- Port 160: Found NoC-Block with ID DDC0000000000000.
> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
> -- Reading XML file: /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
> -- SEND (SID: 00:20>02:a1)...Setting up NoC-Shell Control for port #1
> (SID: 00:20>02:a1)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
> -- Reading XML file: /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
> -- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
> -- block_ctrl_base()
> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
> -- Reading XML file: /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
> -- Found valid blockdef
> -- NOC ID: 0xDDC0000000000000 Block ID: 0/DDC_0
> -- [0/DDC_0] block_ctrl_base::clear()
> -- node_ctrl_base::clear()
> -- [0/DDC_0] block_ctrl_base::_clear()
> -- [0/DDC_0] block_ctrl_base::_clear()
> Traceback (most recent call last):
> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
> line 281, in <module>
> main()
> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
> line 269, in main
> tb = top_block_cls()
> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
> line 66, in __init__
> self.device3 = device3 = ettus.device3(uhd.device_addr_t(
> ",".join(("type=x300", "")) ))
> File
> "/home/nick/clabs/target/lib/python2.7/dist-packages/ettus/ettus_swig.py",
> line 1855, in make
> return _ettus_swig.device3_make(*args, **kwargs)
> RuntimeError: EnvironmentError: IOError: [0/DDC_0] sr_read64() failed:
> EnvironmentError: IOError: Radio ctrl (CE_07_Port_160) no response packet -
> AssertionError: bool(buff)
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at
> /home/nick/clabs/clabs_15/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
>
>
> The DDC is a fairly complex block -- any ideas where to look for this one?
>
> --n
>
> _______________________________________________
> 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/20160613/bf46051a/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 13 Jun 2016 17:38:15 +0000
From: Nick Foster <[email protected]>
To: Martin Braun <[email protected]>, [email protected]
Subject: Re: [USRP-users] rfnoc-radio-redo and RX path
Message-ID:
<CA+JMMq-z=JH+P-w546ojKnRAaBw2Sd5Qnyy=n-yz4w7n2w2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
BasicRX (and TX) doesn't work at all with rfnoc-radio-redo right now,
because the Radio block doesn't support the "RXA/RXB" antenna names. I'll
hack that into place and give it a shot...
Yeah OK. Also BasicRX gives:
RuntimeError: AssertionError: set_tx_gain: could not apply gain for this
daughterboard.
...which is itself a copy/paste error, because it's set_rx_gain which is
failing, in lib/usrp/x300/x300_radio_ctrl_impl.cpp. Demoting that to a
warning via UHD_MSG gives... yeah, OK, there's the signal. So it looks like
WBX just isn't tuning on initialization.
Good call on board side. It works on side B, but not on side A.
--n
On Mon, Jun 13, 2016 at 10:05 AM Martin Braun via USRP-users <
[email protected]> wrote:
> Nick,
>
> is this dboard-dependent? Does a BasicRX work? And does the side matter?
>
> M
>
>
> On 06/09/2016 11:24 AM, Nick Foster via USRP-users wrote:
> > Hi guys,
> >
> > Having some trouble on rfnoc-radio-redo trying to simply receive
> > something with a WBX.
> >
> > FG just looks like this:
> >
> > pasted1
> > ? // //
> >
> >
> > Only receiving very low-level noise on the output. No indication of
> > signal (flat spectrum, faint DC offset), though there is CW being put
> > into the front end. The output appears independent of both gain and
> > frequency setting in the RFNoC Radio block. I don't even care about the
> > integrity of the signal -- obviously Keep 1 in N isn't going to do me
> > any favors there. Just trying to prove I'm hearing anything at all with
> > this simple flowgraph.
> >
> > Any hints?
> > --n
> >
> >
> > _______________________________________________
> > 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/20160613/7da3b9c2/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 13 Jun 2016 12:38:38 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Error when running noc_block_fir_filter_tb
in Modelsim in rfnoc-radio-redo branch : cannot open wave.do file
Message-ID:
<CAGdo0uRQvt6-g1nbsnd=fxTKwGk=0srcqnqunxfykfx7mll...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Craig,
Fixed, but it will be a few days until the fix is pushed.
Jonathon
On Fri, Jun 10, 2016 at 8:01 AM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> When I run the simulation, it gets far enough to open Modelsim but errors
> out here:
>
>
> Time: 0 ps Iteration: 0 Instance:
> /noc_block_fir_filter_tb/noc_block_fir_filter/inst_axi_round_and_clip/split
> File: ../../../../../split_complex.v
> # ** Warning: (vsim-3722) ../../../../../axi_round_and_clip_complex.v(20):
> [TFMPC] - Missing connection for port 'error'.
> # ** Warning: (vsim-3017) ../../../../../axi_round_and_clip_complex.v(35):
> [TFMPC] - Too few port connections. Expected 13, found 12.
> # Time: 0 ps Iteration: 0 Instance:
> /noc_block_fir_filter_tb/noc_block_fir_filter/inst_axi_round_and_clip/join_complex
> File: ../../../../../join_complex.v
> # ** Warning: (vsim-3722) ../../../../../axi_round_and_clip_complex.v(35):
> [TFMPC] - Missing connection for port 'error'.
> # .main_pane.wave.interior.cs.body.pw.wf
> # .main_pane.structure.interior.cs.body.struct
> # .main_pane.objects.interior.cs.body.tree
> # ** Error: Cannot open macro file:
> /home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fir_filter_tb/wave.do
> # Error in macro ./noc_block_fir_filter_tb_simulate.do line 19
> # Cannot open macro file:
> /home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fir_filter_tb/wave.do
> # while executing
> # "do
> {/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fir_filter_tb/wave.do}"
>
> ?Craig
>
>
>
> *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.298.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/20160613/8e706413/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 13 Jun 2016 17:39:05 +0000
From: Nick Foster <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-radio-redo DDC block test
Message-ID:
<CA+JMMq96JRA6x3YSVgbLoCxsU3v9esOM8A=wu-m1wqtyksy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Jun 13, 2016 at 10:37 AM Jonathon Pendlum <
[email protected]> wrote:
> This is a new block and still not officially "released," though it should
> work. What block settings are you using, just the default ones in the GRC
> files?
>
Yep, just vanilla rfnoc_ddc from radio-redo branch of gr-ettus.
> Are you using 10GigE or 1GigE?
>
1GigE
> Was this the first run or a subsequent run?
>
Both produce identical results.
--n
>
>
>
> Jonathon
>
> On Thu, Jun 9, 2016 at 10:06 PM, Nick Foster via USRP-users <
> [email protected]> wrote:
>
>> Trying to get the gr-ettus/examples/rfnoc_ddc.grc example working, and
>> getting the following:
>>
>> -- [RFNOC] ------- Block Setup -----------
>> -- SEND (SID: 00:1f>02:a0)...Setting up NoC-Shell Control for port #0
>> (SID: 00:1f>02:a0)...OK
>> -- Port 160: Found NoC-Block with ID DDC0000000000000.
>> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
>> -- Reading XML file:
>> /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
>> -- SEND (SID: 00:20>02:a1)...Setting up NoC-Shell Control for port #1
>> (SID: 00:20>02:a1)...OK
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
>> -- Reading XML file:
>> /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
>> -- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
>> -- block_ctrl_base()
>> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
>> -- Reading XML file:
>> /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
>> -- Found valid blockdef
>> -- NOC ID: 0xDDC0000000000000 Block ID: 0/DDC_0
>> -- [0/DDC_0] block_ctrl_base::clear()
>> -- node_ctrl_base::clear()
>> -- [0/DDC_0] block_ctrl_base::_clear()
>> -- [0/DDC_0] block_ctrl_base::_clear()
>> Traceback (most recent call last):
>> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
>> line 281, in <module>
>> main()
>> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
>> line 269, in main
>> tb = top_block_cls()
>> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
>> line 66, in __init__
>> self.device3 = device3 = ettus.device3(uhd.device_addr_t(
>> ",".join(("type=x300", "")) ))
>> File
>> "/home/nick/clabs/target/lib/python2.7/dist-packages/ettus/ettus_swig.py",
>> line 1855, in make
>> return _ettus_swig.device3_make(*args, **kwargs)
>> RuntimeError: EnvironmentError: IOError: [0/DDC_0] sr_read64() failed:
>> EnvironmentError: IOError: Radio ctrl (CE_07_Port_160) no response packet -
>> AssertionError: bool(buff)
>> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>> at
>> /home/nick/clabs/clabs_15/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
>>
>>
>> The DDC is a fairly complex block -- any ideas where to look for this one?
>>
>> --n
>>
>> _______________________________________________
>> 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/20160613/fa6e7175/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 13 Jun 2016 12:41:11 -0500
From: Jonathon Pendlum <[email protected]>
To: devin kelly <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] RFNoC on the E310
Message-ID:
<cagdo0uso5g3pd_lqqz1gbkfnbg6ma4egxu_xcy_gp-rwgt1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Devin,
You should cross compile UHD, GNU Radio, and gr-ettus. This is a useful
since RFNoC development has been moving quickly lately. We don't have a
definite release date for an updated image, but it should be in the next
month or so.
Jonathon
On Fri, Jun 10, 2016 at 1:44 PM, devin kelly via USRP-users <
[email protected]> wrote:
> Hello,
>
> I'd like to use RFNoC on the E310 with the Release 4 image, a somewhat new
> version of GNU Radio and the UHD.
>
> As I understand it there are a few things I need to get right.
>
> The FPGA bit image file (have the same version as the installed UHD, must
> have RFNoC enabled)
> The UHD library install (consistent version and RFNoC enabled)
> GNU Radio (compiled against the same version of the UHD and with some E310
> flags?)
>
> The UHD and GNU Radio installs on the release 4 image are UHD_003.009.002
> and 3.7.9 respectively. Neither of them are enabled for use with RFNoC as
> far as I can tell.
>
> So does this mean that to get UHD+GR working on the release 4 image I
> would have to cross-compile UHD and GR and then install them over the
> existing UHD+GR installs on the E310? Is there an easier way or should I
> just use the fido-rfnoc-test image? Is there a more up to date RFNoC image
> coming out anytime in the next week or two?
>
> Devin
>
> _______________________________________________
> 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/20160613/d971db5a/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 13 Jun 2016 10:57:27 -0700
From: Michael West <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UBX Tx-to-Rx interference, Performance and
Power-Save modes
Message-ID:
<CAM4xKrqwxw6UbrU7P3AEPCu==61Sdr6Z__NeoGai=aj-cua...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI Hanwen,
As Martin indicated, all the UBX fixes in the patch have been pushed into
the maint branch. You should change over to using that.
At 2.6GHz, the TX power of the UBX is ~1dB lower than SBX at the same gain
setting. The performance data for the daughterboards can be found here:
http://files.ettus.com/performance_data/
With the recent UBX changes, there is a 20 microsecond settling time at the
start of the transmit stream where the output power is low. You may need
to zero pad the beginning of the stream and start it 20 microseconds early.
Regards,
Michael
On Mon, Jun 13, 2016 at 10:00 AM, Martin Braun via USRP-users <
[email protected]> wrote:
> Hanwen,
>
> all the fixes we have cooked up recently are on maint (and master). Are
> you still having issues?
>
> Cheers,
> Martin
>
> On 06/12/2016 12:04 PM, hanwen via USRP-users wrote:
> > Hi Michael,
> >
> > Any new progress in improving UBX support in UHD? Thanks.
> >
> > Br, Hanwen
> >
> > 2016-05-26 12:50 GMT+02:00 hanwen <[email protected]
> > <mailto:[email protected]>>:
> >
> > Hi Michael,
> >
> > No difference with this patch. The transmitted signal is too weak,
> > confirmed by an additional spectrum analyzer as receiver.
> > I noticed that in the patch, many "FORCEON" are set to 0 in the
> > performance, could it be the reason that the Tx power is so low?
> >
> > Br, Hanwen
> >
> > 2016-05-24 22:14 GMT+02:00 Michael West <[email protected]
> > <mailto:[email protected]>>:
> >
> > Hi Hanwen,
> >
> > Thanks for the feedback. Can you remove the previous patches
> > and apply the new one attached? It is slightly different than
> > the previous one. I tested and had no issues with it.
> >
> > Regards,
> > Michael
> >
> > On Tue, May 24, 2016 at 12:48 PM, hanwen
> > <[email protected] <mailto:[email protected]>>
> wrote:
> >
> > HI Michael,
> >
> > I tested your new patch today. At the Rx side, yes, the
> > noise floor low and doesn't affected by Tx. BUT, the Tx
> > power is also low and it looks like the same as with the
> > powersave mode in my TDMA/TDD system configuration. Thanks.
> >
> > Br, Hanwen
> >
> > 2016-05-24 0:43 GMT+02:00 Michael West
> > <[email protected] <mailto:[email protected]>>:
> >
> > Hi Hanwen,
> >
> > We see the same results. Further investigation into the
> > issue has yielded the attached updated patch. We are
> > still working on the issue, but please try the patch and
> > let me know if it improves the noise figure for you. It
> > should work well in performance or powersave mode.
> >
> > Regards,
> > Michael
> >
> > On Mon, May 23, 2016 at 1:35 PM, hanwen
> > <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Hi Michael,
> >
> > Thanks for the patch. I tried today and it fixed the
> > issue that the Rx noise floor raises along with the
> > increasing Tx gain.
> > But it seems in the default performance mode, the
> > noise floor is higher than in the powersave mode and
> > the actual noise figure is also poorer. I'll do some
> > further test tomorrow and try to tweak the CPLD
> > field options in db_ubx.cpp.
> >
> > Br, Hanwen
> >
> > 2016-05-19 19:47 GMT+02:00 Michael West
> > <[email protected]
> > <mailto:[email protected]>>:
> >
> > Hi Hanwen,
> >
> > There is an issue for UBX in TDD mode of which
> > we are aware and in the process of fixing. In
> > the meantime, apply the attached patch and use
> > the default (performance) power mode and let me
> > know if it helps.
> >
> > Regards,
> > Michael
> >
> > On Wed, May 18, 2016 at 9:03 PM, hanwen
> > <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Dear USRP users and experts,
> >
> >
> >
> > Instructed by Michael
> > in:
> https://www.mail-archive.com/[email protected]/msg01766.html
> >
> > I tried the switching between powersave and
> > performance mode for the new UBX and did
> > some further test.
> >
> >
> >
> > Basic config: 11.42MS/s, Carrier: 2.6GHz,
> > TDMA mode with 1ms time slot and one device
> > switches between Tx and Rx every 1ms; UHD
> > and firmware are the fresh 3.9.4 release.
> >
> >
> >
> > * *
> >
> >
> >
> > *Power Save*
> >
> >
> >
> > *Performance*
> >
> > *Tx*
> >
> >
> >
> > The transmitted signal is very weak no
> > matter what Tx gain is chosen
> >
> >
> >
> > The transmission is fine, but the maximum Tx
> > power is 2~3dB lower than SBX
> >
> > The device is getting very hot
> >
> > *Rx*
> >
> >
> >
> > The noise floor not affected by Tx
> >
> >
> >
> > Noise floor rising up by c.a. 7dB by setting
> > to higher Tx gain (>21.5), EVEN WHEN no
> > transmission in Tx slot
> >
> >
> >
> > In the attachment you could see some
> > screenshots:
> >
> > ? Tg_1.5~31.5.png: showing the
> > rising Rx noise floor in the default
> > Performance mode
> >
> > ? Cst_performance/powersave.png:
> > showing in the Powersave mode: the
> > constellation demodulated at another device
> > is very poor due to weak transmit power.
> >
> >
> >
> > For both powersave and performance mode we
> > observed unacceptable problems for our
> > system, but using the older SBX-40 and SBX
> > 120 boards we didn?t observe these problems.
> >
> >
> >
> > Bests, Hanwen
> >
> >
> >
> > ???? 7???? 8???? 9???? 10?
> > ??? 11???? 12
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/20160613/d1eb28fd/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 13 Jun 2016 11:01:18 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RFNoC on the E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Devin,
installing UHD and setting up the cross-compile env is what most people
seem to stumble over. We have a PyBOMBS recipes that does all of that
for you, the recipe is available at
https://github.com/EttusResearch/ettus-pybombs
If you set it up correctly, you can do
$ pybombs prefix init -R e3xx-radio-redo <path>
to set it all up. This process takes a while.
We have a knowledge base article on this here:
https://kb.ettus.com/Software_Development_on_the_E310_and_E312
...but it doesn't include PyBOMBS (yet). I'll be adding that soon.
Cheers,
M
On 06/10/2016 11:44 AM, devin kelly via USRP-users wrote:
> Hello,
>
> I'd like to use RFNoC on the E310 with the Release 4 image, a somewhat
> new version of GNU Radio and the UHD.
>
> As I understand it there are a few things I need to get right.
>
> The FPGA bit image file (have the same version as the installed UHD,
> must have RFNoC enabled)
> The UHD library install (consistent version and RFNoC enabled)
> GNU Radio (compiled against the same version of the UHD and with some
> E310 flags?)
>
> The UHD and GNU Radio installs on the release 4 image
> are UHD_003.009.002 and 3.7.9 respectively. Neither of them are enabled
> for use with RFNoC as far as I can tell.
>
> So does this mean that to get UHD+GR working on the release 4 image I
> would have to cross-compile UHD and GR and then install them over the
> existing UHD+GR installs on the E310? Is there an easier way or should
> I just use the fido-rfnoc-test image? Is there a more up to date RFNoC
> image coming out anytime in the next week or two?
>
> Devin
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Mon, 13 Jun 2016 12:03:41 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] RFNoC on the E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/13/2016 11:01 AM, Martin Braun wrote:
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>
> ...but it doesn't include PyBOMBS (yet). I'll be adding that soon.
It actually does include a section on PyBOMBS, thanks to our trusty interns.
M
------------------------------
Message: 17
Date: Tue, 14 Jun 2016 08:29:46 -0400
From: "Joshua Monson" <[email protected]>
To: "'Neel Pandeya'" <[email protected]>
Cc: "'usrp-users'" <[email protected]>
Subject: Re: [USRP-users] Custom Board
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Neel,
Thanks for responding. We are trying to implement an OFDM modem working in CSMA
and TDD mode using E310. We plan to implement the complete PHY and some
time-sensitive MAC functions such as ACK/NAK in FPGA logic (potentially with a
real-time processor unit); and the rest MAC layer functions in one or both ARM
cores. IN terms of RF frontend control, while we could leverage UHD to
initialize the AD9361, in order to support ACK/NAK, the TDD operation, and
multi-node communications, we need to control AGC and Tx/Rx switch from FPGA
during runtime.
At this point, we?re trying to come up with a baseline design that brings the
platform up correctly in a safe state (i.e. in a state that won?t damage other
on-board components) so that we can begin our software and hardware
development. In addition, we?d like to save as much space for our own hardware
as possible. Initially, I tried to export the ?E3XX_Idle? Vivado Project (from
fpga_src in the UHD git tree) to Xilinx SDK; however, apparently Vivado does
not allow this because the top-level design does not originate from IP
Integrator. My current attempt is a port of the main components of the
E3XX_idle project to an IP Integrator project that I have creates. This
includes an exact copy of the PS configuration from the E3XX_idle project,
importing the constraint (XDC) files, importing the PMU SPI core, and driving
the same constant values to the PL I/O. I was able to build this and created
an SD Card Image and the FPGA fabric appears to configure but the UART is
unresponsive (I?v
e written a small program that prints ?*? continuously).
We realize that this is not a perfect path forward, primarily, because, it does
not allow us to leverage your drivers or hardware for the RF front-end. (our
plan was to fall back to the drivers provided by Analog Devices) Ideally, we
desire to leverage as much of your pre-built software and hardware as possible,
but, it appears that building off of your existing reference design would
require us to make some significant changes to UHD (this may be a misconception
on our part). For example, we?d be willing to use the existing reference
design/UHD if we were able to remove the ?radio? components without breaking
the UHD software (or having to modify it significantly).
Do you have any guidance on potential design flows or entry point that could
help us to utilize the software and hardware you already provide?
Thanks,
Josh
From: Neel Pandeya [mailto:[email protected]]
Sent: Monday, June 13, 2016 12:17 PM
To: Joshua Monson <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Custom Board
Hello Josh:
We basically don't use IP integrator for any of our Vivado development, and so
we're not really familiar with how it works. I know that there are no
auto-generated headers for our stuff, so there is nothing that you could export
to the Xilinx SDK.
Could you describe in more detail exactly what you're trying to do?
Thanks.
--Neel Pandeya
On 13 June 2016 at 08:12, Joshua Monson via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
From: Joshua Monson [mailto: <mailto:[email protected]> [email protected]]
Sent: Thursday, June 9, 2016 3:17 PM
To: 'Matt Ettus' < <mailto:[email protected]> [email protected]>
Subject: RE: [USRP-users] Custom Board
Matt,
I agree whole-heartedly with you and that is what I attempted to do initially.
Unfortunately, I ran into a roadblock in which Vivado would not export the PS
configuration and address mappings to the SDK unless the Zynq processing system
was declared in a top-level IP integrator design. How did you guys get around
this Vivado restriction? It seems to me that even though you?re using Linux you
would still need that Vivado to generate the device tree source and PS
configuration files.
Thanks,
Josh
From: Matt Ettus [ <mailto:[email protected]> mailto:[email protected]]
Sent: Thursday, June 9, 2016 2:39 PM
To: Joshua Monson < <mailto:[email protected]> [email protected]>
Cc: <mailto:[email protected]> [email protected]
Subject: Re: [USRP-users] Custom Board
Joshua,
While you are welcome to try this, you have chosen an extremely difficult path.
There is a lot of complexity in a board like this. You would be far better
off if you started with our top level design an removed the parts you don't
want, rather than try to recreate everything in a vacuum. Otherwise, you'll
need to look at the schematics to make sure every pin is driven properly.
Matt
On Thu, Jun 9, 2016 at 8:43 AM, Joshua Monson via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Hi,
We?re developing a custom bare-metal FPGA design for the USRP E310. The plan is
to have the FPGA configured with this design via an SDCard image when the board
powers up. To begin our development we?d like to start with minimal FPGA design
that can bring the board up safely without damaging the other components. To
this end I?ve created an initial design in Xilinx Vivado by importing the PS
configurations (presets) from the E3XX_idle design in UHD. On the FPGA side
(PL), I?ve imported and integrated the AXI PMU and constant logic values
connected to external I/O (also from E3XX_idle). I?ve also imported the
constraint files from E3XX_idle to ensure the I/O voltage levels are configured
properly.
Is there anything else that I need to do to ensure that the board and FPGA
powers on properly?
Thanks,
Josh
_______________________________________________
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/20160614/13be1564/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 14 Jun 2016 21:43:57 +0900
From: Jeon <[email protected]>
To: USRP users mailing list <[email protected]>
Subject: [USRP-users] Effective a length of VERT2450 antenna and its
impact on receiving signal.
Message-ID:
<CACfn7v6m-7cMokdM_BhxL16cDvVbiLjfCpkztrsLcupZev=o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear USRP users,
I wonder that how long a length of VERT2450 antenna inside plastic cover is.
Currently, I am trying to measure channel matrix, channel state information
(magnitude and phase of each OFDM subcarrier) of Wi-Fi.
And also I am curious whether a length of VERT2450 antenna has an impact of
measuring magnitude and phase of each OFDM subcarrier. (e.g., incorrect
antenna length results in incorrect channel state information.)
Frankly speaking, I am using not USRP, but only VERT2450 antenna. I am
using it with connected to Atheros 802.11n Wi-Fi card. (ath9k series;
AR9580, etc.)
The last small question is,does a length of a cable, and shielding
connecting VERT2450 and Wi-Fi card (or duaghterboard) have an impact on
channel matrix?
Regards,
Jeon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/7d818297/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 14 Jun 2016 15:12:51 +0200
From: Sumit Kumar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Reg : Invoking FPGA functions thru C program
Message-ID:
<caoextcrsywfpkzyz1zu9tqalkvu3dyded-l+yfy6a17mze1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This is a very basic question I guess. Suppose I write my own function in
Verilog for B210 FPGA, how will I execute that function from my own C
program.
Context : Developing MAC layer for 802.11a. Writing some functions to be
implemented inside FPGA.
Any pointers on this. Its a very new work for me and I am puzzled.
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/6bd0a64b/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 14 Jun 2016 07:14:23 -0600
From: Steven Knudsen <[email protected]>
To: Jeon <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Effective a length of VERT2450 antenna and
its impact on receiving signal.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Good places to start reading and learning would be
http://www.arrl.org/antennas <http://www.arrl.org/antennas>
http://www.arrl.org/arrl-antenna-book <http://www.arrl.org/arrl-antenna-book>
and there may be some good starting points here
http://www.antenna-theory.com/ <http://www.antenna-theory.com/>
For your particular topic, I?d start by reading IEEE journals as much work has
been published on channel characterization. There you will find the answer to
your last question is ?yes?.
Finally, it?s likely worth searching for theses and dissertations on the topic.
I remember a few published back in the late 90s early 2000s by students at my
university.
Good luck.
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
> On Jun 14, 2016, at 06:43, Jeon via USRP-users <[email protected]>
> wrote:
>
> Dear USRP users,
>
> I wonder that how long a length of VERT2450 antenna inside plastic cover is.
>
> Currently, I am trying to measure channel matrix, channel state information
> (magnitude and phase of each OFDM subcarrier) of Wi-Fi.
>
> And also I am curious whether a length of VERT2450 antenna has an impact of
> measuring magnitude and phase of each OFDM subcarrier. (e.g., incorrect
> antenna length results in incorrect channel state information.)
>
> Frankly speaking, I am using not USRP, but only VERT2450 antenna. I am using
> it with connected to Atheros 802.11n Wi-Fi card. (ath9k series; AR9580, etc.)
>
> The last small question is,does a length of a cable, and shielding connecting
> VERT2450 and Wi-Fi card (or duaghterboard) have an impact on channel matrix?
>
> Regards,
> Jeon.
> _______________________________________________
> 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/20160614/e603d63f/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 70, Issue 14
******************************************
