Hi all,
I am trying to build a custom FPGA image for my X310 (daughterboards=UBX-160)
using the uhd_image_builder gui and trying to use the following blocks:
fft
schmidl_cox
eq
ofdm_constellation_demapper
as the code is running and building, it always stops on this error:
'
[00:22:41] Cu
On 09/27/2018 07:09 PM, Jason Meyer wrote:
The command produces output as if there is no issue. It shows the
progress of the image being loaded, and at the end states that the
process was a success and to power-cycle to see the changes made.
However when I power-cycle, I am unable to communicat
I don't believe so, as I copy/pasted the bit file path from Vivado to the
terminal. So I know I am using the same bit file for uhd_image_loader as I
am for the JTAG programming, which is working fine.
Thanks,
Jason
On Thu, Sep 27, 2018 at 7:17 PM Wade Fife wrote:
> Is it possible that you're l
Is it possible that you're loading the wrong .bit file (not the X310
version) from the command line?
Wade
On Thu, Sep 27, 2018, 6:11 PM Jason Meyer via USRP-users <
usrp-users@lists.ettus.com> wrote:
> The command produces output as if there is no issue. It shows the progress
> of the image bein
The command produces output as if there is no issue. It shows the progress
of the image being loaded, and at the end states that the process was a
success and to power-cycle to see the changes made. However when I
power-cycle, I am unable to communicate with the USRP until I load the FPGA
image via
I've used both 3.10.3 and 3.14 (latest git master)
double time_to_transmit = 2.0;
uhd::tx_metadata_t md;
md.start_of_burst = false;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(time_to_transmit);
//then while loop through samples
//get burst ack
On 9/27/20
On 09/27/2018 06:34 PM, Jason Meyer wrote:
Hi Marcus,
I am using UHD v3.11.1.0. The command format I've used is:
uhd_image_loader --args="type=x300,addr=192.168.10.2"
--fpga-path="/usr/local/share/uhd/images/.bit"
Does the command produce any output?
How are you confirming that it's revert
Hi Marcus,
I am using UHD v3.11.1.0. The command format I've used is:
uhd_image_loader --args="type=x300,addr=192.168.10.2"
--fpga-path="/usr/local/share/uhd/images/.bit"
Jason
On Thu, Sep 27, 2018 at 5:28 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 09/27/2018
On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users wrote:
I set the device time stamp to zero and immediately send the packets
to the device with a timestamp of 2.0 seconds. Also wouldn't a past
timestamp give late packet error?
Thanks,
Mitch
Could you show us how you're setting the met
I set the device time stamp to zero and immediately send the packets to
the device with a timestamp of 2.0 seconds. Also wouldn't a past
timestamp give late packet error?
Thanks,
Mitch
On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users wrote:
On 09/27/2018 05:02 PM, Mitch Grabner via USRP-u
On 09/27/2018 03:46 PM, Jason Meyer via USRP-users wrote:
Hello,
I have been working with multiple X310 USRPs and attempting to load
custom FPGA firmware onto the motherboard EEPROM using the
uhd_image_loader command. The command appears to be successful, but
the FPGA fails to load the image
On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users wrote:
Hello,
I'm trying to get a timed burst working on a B200 and it looks like
the device is transmitting the samples the instant they reach the
device (tested by listening on a second device) instead of holding
them until the time speci
Hello,
I'm trying to get a timed burst working on a B200 and it looks like the
device is transmitting the samples the instant they reach the device
(tested by listening on a second device) instead of holding them until the
time specified in md.time_spec.
I set up the first packet's metadata with s
Hello,
I have been working with multiple X310 USRPs and attempting to load custom
FPGA firmware onto the motherboard EEPROM using the uhd_image_loader
command. The command appears to be successful, but the FPGA fails to load
the image on reboot. The image functions just fine when I program it
thro
Hi,
I am just getting started on some custom RFNoC development and trying to
decide how to approach the problem. Essentially, I want to implement a
pair of filters in the frequency domain. It is similar to a pair of FIR
filters (on a block-by-block basis) but I want the capability for very long
f
On 09/27/2018 12:27 PM, Ryan Campiz via USRP-users wrote:
Trip,
Thanks for the tip. I did try at 10 MHz and got slightly better
performance. I can't go higher than 20 MHz on my Function Generator.
Just for reference, this is what I saw on my Network Analyzer.
image.png
This is what I saw fro
Hello everyone,
I have been running different examples with the RFNoC blocks and an
X310, specially with the RFNoC:FFT block, and everything went fine until
I have decided to change the FFT size from 256 (by default) to 64. Then
I had this error:
Traceback (most recent call last):
File "/t
Hi Marcus,
we've gone and updated UHD (HEAD of remotes/origin/UHD-3.13) and changed
the MTU to 8000, unfortunately the problem still persists. A TCP dump as
discussed before is downloadable via: https://we.tl/t-zTKY2iHAlK.
Note that 192.168.50.1 is the host and 192.168.50.2 is the X300. The
do
18 matches
Mail list logo
