Jonathon,
Thanks for the early Saturday (or late Friday) reply.
On Sat, Mar 9, 2019 at 1:13 AM Jonathon Pendlum
wrote:
> Hey Nick,
>
> The DDC and the DUC (or any other block using axi_rate_change) will not
> modify the packet size. Very small packets can cause underruns once the
> header
You've got a dual-install issue here.
On Sat, Mar 9, 2019 at 2:35 PM Thomas Lavarenne via USRP-users <
usrp-users@lists.ettus.com> wrote:
> uhd_probe seems good, but same error in GNU Radio.. (RuntimeError:
> RuntimeError: Expected FPGA compatibility number 14, but got 16:)
>
> $ uhd_usrp_probe
Hi Joe,
Yes that was the reason for why i installed latest uhd from source.
Thank you, I will search in this direction!
I' m using Gnu radio Companion 3.7.11
Le sam. 9 mars 2019 à 20:35, Joe Martin a écrit :
> Hi Thomas,
>
> I also am new to USRP so if I tell you something that is not correct
…and I’m using GNURadio version 3.7.13.4.
Joe
> On Mar 9, 2019, at 12:35 PM, Joe Martin via USRP-users
> wrote:
>
> Hi Thomas,
>
> I also am new to USRP so if I tell you something that is not correct perhaps
> someone more knowledgeable will weigh in and correct me for both our
>
Hi Thomas,
I also am new to USRP so if I tell you something that is not correct perhaps
someone more knowledgeable will weigh in and correct me for both our benefits.
The error you received indicates (I think) that the FPGA firmware version and
the UHD version you have installed are
uhd_probe seems good, but same error in GNU Radio.. (RuntimeError:
RuntimeError: Expected FPGA compatibility number 14, but got 16:)
$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.15.0.git-60-g98d2572a
[INFO] [B200] Loading firmware image:
On 03/09/2019 02:00 PM, Thomas Lavarenne via USRP-users wrote:
Yes, it worked, but the script were on /usr/lib/uhd/utils/ and same
error...
sudo /usr/lib/uhd/utils/uhd_images_downloader.py
[sudo] Mot de passe de user :
[INFO] Images destination: /usr/share/uhd/images
[INFO] Target
Yes, it worked, but the script were on /usr/lib/uhd/utils/ and same error...
sudo /usr/lib/uhd/utils/uhd_images_downloader.py
[sudo] Mot de passe de user :
[INFO] Images destination: /usr/share/uhd/images
[INFO] Target usrp1_b100_fw_default is up to date.
[INFO] Target x3xx_x310_fpga_default is
On Sat, Mar 9, 2019 at 1:45 PM Thomas Lavarenne via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
> I'm new here and pretty new with usrp. I'm trying to use usrp-2900 with
> GNU Radio and Ubuntu 18.04, but i have this problem (latest driver uhd from
> source):
>
> '''
> linux; GNU C++
Hello,
I'm new here and pretty new with usrp. I'm trying to use usrp-2900 with GNU
Radio and Ubuntu 18.04, but i have this problem (latest driver uhd from
source):
'''
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
-- Loading firmware image:
Thank you Mark-Jan for the additional information. I’ll study it and compare
with my system. Much appreciated.
Best regards,
Joe
> On Mar 9, 2019, at 11:19 AM, Mark-Jan Bastian wrote:
>
> Hi Joe,
>
> With sudo lspci -vvv you will see the capabilties, including the low-level
> PCIe bus
Hi Joe,
With sudo lspci -vvv you will see the capabilties, including the low-level
PCIe bus speed and link count negotiation of the devices. The sudo is needed
to get the low-level LnkCap and LnkCtl bits:
For a 16-lane videocard on a laptop here, likely soldered right on the
motherboard:
The
My apologies, I meant to say “Mark-Jan”!
> On Mar 9, 2019, at 10:40 AM, Joe Martin wrote:
>
> Hi Mark,
>
> I am intrigued by your response and have obtained a tree view for my system
> as you suggested to Paul. I’m unfamiliar with the tree view and don’t
> understand how to check the
Hi Mark,
I am intrigued by your response and have obtained a tree view for my system as
you suggested to Paul. I’m unfamiliar with the tree view and don’t understand
how to check the number of PCIe lanes that are available to the disk controller
and disks and how to check how many PCIe
Hi Paul,
Thanks for your post. I am new to USRP devices and UHD and GNURadio but I have
recently obtained an X310 with dual TwinRX daughterboards to do pulsar radio
astronomy and I have been exploring exactly the issue you raise in order to
help me with my requirements to record data for
Hi Paul,
I can record from the X310 to disk to nvme x4 PCIe at 800 MB/sec
for a few minutes. There is still a risk of O 's appearing.
First thing to check is the number of PCIe lanes available to the disk
controller and disks, and how many and which PCIe bridges are in between
on your
Hi,
I'm trying to record the full X310 bandwidth, for a few hours, without
any missed samples. Which of course is a bit of a challenge - does
anyone here already achieve this?
We're using a TwinRX, so initially I wanted to record 2x 100MS/s (from
both channels), which amounts to 800MB/s,
Hey Nick,
The DDC and the DUC (or any other block using axi_rate_change) will not
modify the packet size. Very small packets can cause underruns once the
header becomes a large percentage of the overall packet size. I'm surprised
that you are running into underruns at 20 samples per packet as
18 matches
Mail list logo
