EJ, that's a good question; on an E320, the entire image loader takes a
seconds or two of wall time, and I think it should be the same order of
magnitude for E310. However, you should be able to cut that time down
dramatically when loading an image as part of a larger application. Let me
get back
Hi Brent,
What's the ballpark programming time using uhd_image_loader on the e310?
I currently swap in/out fpga images using the args parameter on the e310
since the fpga size is pretty small. In some cases the application
introspects the required fpga resources, and dynamically chooses the
The 3.15 pre-release updates the E310 to use MPM (as you know), and brings
it more in line with other MPM devices. You'll have to use the
`uhd_image_loader` to update the FPGA image; device args are not used by
the UHD session to load the FPGA image. The E310 will still load the FPGA
image at the
Marcus Leach wrote:
>What happens if you specify an fpga image that doesn't actually
>exist?
>Does it error out?
It ignores the bad file, even though the args seem to be making it
pretty far into the process. I still can't find where uhd loads the
.bit file.
I'm using the version on the
Marcus Leach wrote:
>What happens if you specify an fpga image that doesn't actually
>exist?
>Does it error out?
It ignores the bad file, even though the args seem to be making it
pretty far into the process. I still can't find where uhd loads the
.bit file.
I'm using the version on the
After cloning the gnuradio repo, you can edit this file:
https://github.com/gnuradio/gr-recipes/blob/master/uhd.lwr
On Fri, Jun 28, 2019 at 3:39 PM Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> When installing rfnoc using pybombs is it possible to specify the
Hi,
When installing rfnoc using pybombs is it possible to specify the version of
UHD that you want to install? If so, how?
Thanks,
Andy
___
USRP-users mailing list
USRP-users@lists.ettus.com
Maybe the contents of this file will point you in the right direction?
https://github.com/EttusResearch/meta-ettus/blob/master/meta-e31x/recipes-support/uhd/uhd-fpga-images_git.bbappend
On Fri, Jun 28, 2019 at 1:19 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On
On 06/28/2019 04:06 PM, d.des via USRP-users wrote:
Marcus Leach wrote:
See this thread here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-March/046784.html
I understand how it's supposed to work, and it's always worked that way
before including in the outdated
Marcus Leach wrote:
> See this thread here:
>
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-March/046784.html
I understand how it's supposed to work, and it's always worked that way
before including in the outdated
http://files.ettus.com/e3xx_images/e3xx-release-4/ setup.
On 06/28/2019 09:12 AM, d.des via USRP-users wrote:
I found the new SD image and cross-compiler described in
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html
and it seems to work well for the UHD that's pre-installed. I was also
able to build the v3.15.0.0
Have there been any efforts yet to port gr-ettus to the gnuradio master branch?
I made some trials today with gr-ettus under gnuradio-master and at least was
able to compile and install it (except for fosphor which seems to need Qt4).
Automatic conversion of the grc xml files to the yml format
On 06/28/2019 05:10 AM, Jaya Thota wrote:
Thanks Marcus. Shall I perform the calibration (uhd_cal_tx_iq_balance
, uhd_cal_tx_dc_offset ) with 30dB attenuator connected between TX/RX
and RX? Do you this will help?
No, leave the ports unconnceted when you are doing the CAL sequence.
I found the new SD image and cross-compiler described in
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html
and it seems to work well for the UHD that's pre-installed. I was also
able to build the v3.15.0.0 pre-release host code from git and run it
from a sshfs
> So, the "process flow" you've chosen, JTAGing the FPGA image into
> place, is not a usual method for updating the FPGA image on the N310.
> The N310 is itself a computer platform, so has other mechanisms for
> updating the FPGA image:
>
>
Hi all,
I've the same problem with libuhd 3.14.
I've not a solution yet, but I'm trying ti figure out the problem and I
want to share my observations related with this issue.
In my case the problem appears only when I use my custom noc_block (2
inputs - 2 outputs) and only when I'm going to stop
Hi all,
I have been using USRP X310 for almost more than a month. I had no problems
until two days ago. USRP detects only when it is powered on. It gives
various errors when I tried to execute it with srsLTE or OAI codes. *Each
time, I have to use it, I tend to restart it. I am concerned about
17 matches
Mail list logo
