Hi Andrew,
You'll need to have a Xilinx USB programmer (or Digilent JTAG-HS3 probably
works too), purchase this kit https://www.ettus.com/product/details/E-JTAG-4,
and follow these instructions:
https://www.ettus.com/content/files/E-Series_JTAG-AVR_Cable_Getting_Started_Guide_.pdf.
For setting up
On Wed, Dec 19, 2018 at 6:22 PM J M wrote:
> Some of that makes sense to me. Do you know of an open source example
> where something similar to this is done?
>
No, but it shouldn't be too bad to try and simulate. Make a top block with
2 sets of AXI streaming associated with bus_clk, then
Hi Stephan,
I'm not sure if moving the power resolved your issue, but I wanted to
follow up now that we have completed our root cause analysis. The GPSDO
requires a minimum of 5.7V to retain accuracy and the voltage on J509 is
dropping below that during TX and/or RX. The resolution is to first
Hi Florian,
The device arguments are "clock_source" and "time_source". I noticed in
your command you had them as "clock_src" and "time_src". That may be the
source of the problem.
Regards,
Michael
On Mon, Dec 10, 2018 at 11:33 AM Florian Kaltenberger via USRP-users <
Some of that makes sense to me. Do you know of an open source example
where something similar to this is done?
On Wed, Dec 19, 2018 at 4:30 PM Brian Padalino wrote:
> On Wed, Dec 19, 2018 at 4:24 PM J M wrote:
>
>> Potentially, yes the full 200 MHz
>>
>
> Ah, yes. Then you'd need 2
Hi John,
Is there any documentation on using the ILA on an e310 that's running
gnuradio directly?
Thanks,
Andrew
On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum wrote:
> Hi Andrew,
>
> Have you tried using Chipscope to see where the issue is at in your code?
> You want to look at the tvalid and
Hi all,
I'm trying to work with IQ data on the X310 right as it leaves the FPGA to
be transmitted, and also as soon as it is received from the daughtercard.
Is "capture_ddrlvds.v" and "gen_ddrlvds.v" the right place to do this?
Best,
Alex
___
On Wed, Dec 19, 2018 at 4:24 PM J M wrote:
> Potentially, yes the full 200 MHz
>
Ah, yes. Then you'd need 2 connections to the crossbar.
If you didn't need all 200MHz, then you could get away with 2 ports off the
same crossbar connection as well.
I think you would just have each connection
Potentially, yes the full 200 MHz
On Wed, Dec 19, 2018 at 4:14 PM Brian Padalino wrote:
> On Wed, Dec 19, 2018 at 4:06 PM J M wrote:
>
>> The block is performing some signal processing on incoming samples
>> streaming from a radio block, but the signal processing is based on the
>> data stored
On Wed, Dec 19, 2018 at 4:06 PM J M wrote:
> The block is performing some signal processing on incoming samples
> streaming from a radio block, but the signal processing is based on the
> data stored in the ram. It would be ideal to be able to swap out the RAM
> while the block is streaming,
The block is performing some signal processing on incoming samples
streaming from a radio block, but the signal processing is based on the
data stored in the ram. It would be ideal to be able to swap out the RAM
while the block is streaming, though loading it once at start is better
than what we
Great, that worked. Thanks Nick!
For anyone else doing this, the following link also helped when
synthesizing the project in Vivado since there were some files missing:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-June/042575.html
Best,
Alex
On Tue, Dec 18, 2018 at 5:25 PM
On 12/19/2018 02:29 PM, Devin Kelly wrote:
I'm using 500 kHz sampling rate. Wouldn't a lower rate effect my ToF
accuracy? My understanding is that with 500 kHz sample rate my best
ToF accuracy would be 2 us. My next question is why is the ToF
shifting by less than 2 us (1/500e3)? My master
On Wed, Dec 19, 2018 at 12:53 PM J M via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> I'm trying to load a RAM inside an RFNoC block, and doing this via
> register writes takes about a minute and half.
>
> So, looking for a quicker way to load up the data from the RAM, thought
>
I'm using 500 kHz sampling rate. Wouldn't a lower rate effect my ToF
accuracy? My understanding is that with 500 kHz sample rate my best ToF
accuracy would be 2 us. My next question is why is the ToF shifting by
less than 2 us (1/500e3)? My master clock is 16MHz so maybe the ToF shifts
by
On 12/19/2018 01:56 PM, Devin Kelly via USRP-users wrote:
Hello,
I have an X310 transmitting packets to an E310, the E310 can
successfully demodulate the packet and estimate the time of flight.
I'm sending one packet per second for about half an hour and the ToF
estimate is very consistent,
Hello,
I have an X310 transmitting packets to an E310, the E310 can successfully
demodulate the packet and estimate the time of flight. I'm sending one
packet per second for about half an hour and the ToF estimate is very
consistent, except for when I have an overflow on the E310. I get an
Hi all,
Re-posting this question
(https://www.mail-archive.com/usrp-users@lists.ettus.com/msg06892.html). The
use of set_gpio_attr with rfnoc radio_ctrl_impl throws bad allocation error. I
am stuck with this problem for some time and its important for the project I am
working on. Can anyone
Hello,
I have run into this problem regularly. This problem seems to be linked
with the SD card and is not a software issue.
Try the following:
1. Cleanly format the SD card (write all 0's to it) and then use UHD to
image it. I prefer to use CCleaner and windows disk manager. It should take
an
Hi,
I'm trying to load a RAM inside an RFNoC block, and doing this via register
writes takes about a minute and half.
So, looking for a quicker way to load up the data from the RAM, thought
about a second input to the RFNoC block and source it from the file. In
this way, the RFNoC block would
I have a third party app compiled and linked with 3.12.0.0.
I have burned the SD card image for the N310 from here
http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.12.0.0/
to the SD card.
All partitions look proper from another linux machine.
When I boot the N310 with that sd card I
I think I need to rebuild mpm since I rebuilt UHD for the embedded N310.
I tried to rebuild it on the host with cross-compile sourced, but I get this
error that keeps make from working:
CMake Warning at
Hello,
I am trying to synthesize a custom IP core generated by HLS to generate a
RFNoC custom block, but when I run ./uhd_image_builder.py I get the
following error:
*--Using the following blocks to generate image:* myFir*
despFreq* ddc*
Well even if my loop is executing more than 16 times if I use
clear_command_time it should clear the item from FIFO. is this correct ? or
any other command for clearing the timed-commands queue.
uhd::time_spec_t temp = usrp_sourceDOA1->get_time_now();
24 matches
Mail list logo
