Hi Zack
your /etc/default/grub is Ok.
This problem may be caused by a NIC device driver. Can you upgrade the DPDK
version?
I use Ubuntu 22 and UHD 4.4 and DPDK 21.
Regards,
2024年3月14日(木) 23:55 :
> Hi Mikio,
>
> Below are the contents of /etc/default/grub
>
> # If you change this file, run
Hello Martin,
I am currently using two command prompt windows for debug information\
\
This is the first command prompt window where I logged into the n310 and ran
both systemctl stop usrp-hwd and usrp_hwd.py -v commands and after running the
uhd_usrp_probe command on the host computer:
\
On 14/03/2024 12:56, Jim Grubb via USRP-users wrote:
I have an NI 2944 which I would like to use with gnu radio.
I found the kb article describing how to load the X310 FPGA image here:
https://kb.ettus.com/Running_UHD_and_GNU_Radio_on_NI_USRP-RIO
I’d like to know how to find the IP address
I have an NI 2944 which I would like to use with gnu radio.
I found the kb article describing how to load the X310 FPGA image here:
https://kb.ettus.com/Running_UHD_and_GNU_Radio_on_NI_USRP-RIO
I’d like to know how to find the IP address for the SFP+ 10G E port. Is there
a default address
Hi Mikio,
Below are the contents of /etc/default/grub
```
# If you change this file, run 'update-grub' afterwards to update
```
```
# /boot/grub/grub.cfg.
```
```
# For full documentation of the options in this file, see:
```
```
# info -f grub -n 'Simple configuration'
```
```
Negative times don't make much sense, the device keeps positive times; the -1 was probably
just mean to signifiy "immediately". So, try with, say 10.0 and 10.1 .
Best regards,
Marcus
On 14.03.24 10:00, Tim Vancauwenbergh wrote:
Hi Marcus
Thanks for your reply! I have been experimenting with
Hi Marcus
Thanks for your reply! I have been experimenting with the start time. With the
default being "-1.0" for both tx and rx, I set the tx time within the range of
-0.9 to -0. (to start later than rx) but there does not seem to be a clear
difference in the qt gui time sink.
The delay
Hi Brian,
Great, you've started the hardware daemon mpm on the device and if you now run
the uhd_usrp_probe command (doesn't matter if from the host or from another
shell on the device) it'll most probably run into the same error as before, but
you'll be able to see more detail in the mpm
