[USRP-users] USRP B210 streamer throwing BAD PACKET and TIMEOUT error
Hi, I am using usrp B210 for my 5G test bench setup. The setup is consists of Openairinterface5G 5G stack and UHD driver 4.3.0. UHD driver is installed form source code approach and only one libuhd driver is in use. My setup is as follows, * Intel i7, 8 core, 8GB RAM, 3.6GHz CPU with ubuntu18.04, 4.15.0.123 Low latency kernel. * USB 3.0 connection * Log periodic antenna (**LP0965 Antenna)** Snippet of the error:\ \[HW\] \[recv\] received 14380 samples out of 23040 \[ERROR\] \[STREAMER\] The receive packet handler caught a value exception. ValueError: bad vrt header or packet fragment \[HW\] ERROR_CODE_BAD_PACKET \[PHY\] rx_rf: Asked for 23040 samples, got 14380 from USRP \[PHY\] problem receiving samples \[HW\] \[recv\] received 0 samples out of 23040 \[HW\] ERROR_CODE_TIMEOUT kern.log:\ Nov 14 07:04:43 MYTSP00192 kernel: \[489670.971642\] xhci_hcd :00:14.0: WARN Cannot submit Set TR Deq Ptr Nov 14 07:04:43 MYTSP00192 kernel: \[489670.971644\] xhci_hcd :00:14.0: A Set TR Deq Ptr command is pending. Nov 14 11:54:29 MYTSP00192 kernel: \[507057.294029\] enp4s0: Invalid MTU 9000 requested, hw max 1500 Nov 14 11:54:29 MYTSP00192 kernel: \[507057.592639\] xhci_hcd :00:14.0: bad transfer trb length 7680 in event trb\ \ Please help me.\ \ Regards, Anil ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: USRP B210 streamer throwing BAD PACKET and TIMEOUT error
On 14/11/2023 07:01, anil.ant...@ltts.com wrote: Hi, I am using usrp B210 for my 5G test bench setup. The setup is consists of Openairinterface5G 5G stack and UHD driver 4.3.0. UHD driver is installed form source code approach and only one libuhd driver is in use. My setup is as follows, * Intel i7, 8 core, 8GB RAM, 3.6GHz CPU with ubuntu18.04, 4.15.0.123 Low latency kernel. * USB 3.0 connection * Log periodic antenna (*LP0965 Antenna)* Snippet of the error: [HW] [recv] received 14380 samples out of 23040 [ERROR] [STREAMER] The receive packet handler caught a value exception. ValueError: bad vrt header or packet fragment [HW] ERROR_CODE_BAD_PACKET [PHY] rx_rf: Asked for 23040 samples, got 14380 from USRP [PHY] problem receiving samples [HW] [recv] received 0 samples out of 23040 [HW] ERROR_CODE_TIMEOUT kern.log: Nov 14 07:04:43 MYTSP00192 kernel: [489670.971642] xhci_hcd :00:14.0: WARN Cannot submit Set TR Deq Ptr Nov 14 07:04:43 MYTSP00192 kernel: [489670.971644] xhci_hcd :00:14.0: A Set TR Deq Ptr command is pending. Nov 14 11:54:29 MYTSP00192 kernel: [507057.294029] enp4s0: Invalid MTU 9000 requested, hw max 1500 Nov 14 11:54:29 MYTSP00192 kernel: [507057.592639] xhci_hcd :00:14.0: bad transfer trb length 7680 in event trb Please help me. Regards, Anil Yeah, so there's something wrong with your USB3 subsystem. Maybe a bad cable? Try using the external power supply on the B210 if you aren't already. Also: https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks And you might look into the transport parameters for USB: https://files.ettus.com/manual/page_transport.html ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: X310/UBX Tx tuning issue introduced UHD 4.4?
On 13/11/2023 22:29, Rob Kossler via USRP-users wrote: Hi, I am having an issue with successfully tuning the frequency for the Tx side of an X310/UBX and it appears to me that a bug was introduced in UHD 4.4 (I haven't checked more recent versions, but I expect that they are also affected). The issue is that when you request a frequency such as 2450 MHz, the tune result returns with an actual frequency around 450 MHz, and there does not appear to be an RF signal at the requested frequency. I submitted an issue with Ettus' issue tracker. But, given the severity of this issue, I wanted to check with other users to find out if anyone is using the X310/UBX with UHD 4.4 or above and having success with Tx tuning. If so, then it seems I am wrong. Can anyone confirm one way or the other? Thanks. Rob I haven't tried this myself. There may be others in the support org. who can try to reproduce and I've rattled their cage. If this is real (and it hasn't been fixed in subsequent releases) it's bad. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: N320 AGC
On 13/11/2023 16:48, Steve Hamn wrote: Thanks for the response. Reading that page about the tune_request_t it says "/The daughterboards that support this functionality are: WBX (all revisions), WBX-120, SBX (all revisions), SBX-120, CBX, CBX-120, UBX, UBX-160/" so will that work for the N320? I actually am trying to avoid the DC signal and have manually tuned 2MHz above the LO (fc=220MHz, BW=2MHz-4MHz) but still see this behavior. The N320 uses an architecture that pretty-much *requires* that offset-tuning work, in my previous response, I had mis-read your message--sorry. Your strategy would be to offset-tune so that the DC anomaly is just outside your passband, as defined by your sample rate. Another thing is that when debugging issues like this, it can be VERY VERY useful to perform some kind of spectral analysis on the data. You may well have an interfering signal that is dominating your samples, and without doing an FFT, you'd never know. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] x410 stuck in reboot
Hello,
I recently tried to update the x410 FPGA over SSH. However, I was met with a
strange error, and now when I try to log into the x410, even over console JTAG,
I am unable to. It appears the x410 is caught in a reboot loop.
Below is the message I got when trying to update the x410.
\[ERROR\] \[UHD\] An unexpected exception was caught in a task loop.The task
loop will now exit, things may not work.rpc::timeout: Timeout of 1ms while
calling RPC function 'reclaim'
\[ERROR\] \[UHD\] Exception caught in safe-call.
in \~mpmd_mboard_impl
at /home/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp:322
dump_logs(); _claimer_task.reset(); if (not
rpc->request_with_token("unclaim")) { uhd::_log::log(uhd::log::warning,
"/home/frosty/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp", 324,
"MPMD", std::this_thread::get_id()) << "Failure to ack unclaim!";; } ->
rpc::timeout: Timeout of 1ms while calling RPC function 'get_log_buf'
Error: rpc::timeout: Timeout of 12ms while calling RPC function
'update_component'
Thanks
Joe
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: X310/UBX Tx tuning issue introduced UHD 4.4?
Slight update. When the tune result reports the actual frequency as 450 MHz for a requested frequency of 2450 MHz, the 450 MHz represents an LO at 360 MHz and a digital IF of 90 MHz. Not sure why but that is what is happening. The digital IF is truly at 90 MHz. The LO is not at 360 MHz but at the requested 2450 MHz. Thus, when I checked for the signal yesterday, it was not at the requested frequency only because of the digital IF. If I set the digital IF to 0, then the signal shows up at 2450 MHz (but still reporting that it is at 360 MHz). On Tue, Nov 14, 2023 at 10:45 AM Marcus D. Leech wrote: > On 13/11/2023 22:29, Rob Kossler via USRP-users wrote: > > Hi, > I am having an issue with successfully tuning the frequency for the Tx > side of an X310/UBX and it appears to me that a bug was introduced in UHD > 4.4 (I haven't checked more recent versions, but I expect that they are > also affected). The issue is that when you request a frequency such as > 2450 MHz, the tune result returns with an actual frequency around 450 MHz, > and there does not appear to be an RF signal at the requested frequency. > > I submitted an issue with Ettus' issue tracker. But, given the severity of > this issue, I wanted to check with other users to find out if anyone is > using the X310/UBX with UHD 4.4 or above and having success with Tx > tuning. If so, then it seems I am wrong. Can anyone confirm one way or > the other? > Thanks. > Rob > > I haven't tried this myself. There may be others in the support org. who > can try to reproduce and I've rattled their cage. > If this is real (and it hasn't been fixed in subsequent releases) it's > bad. > > > > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: x410 stuck in reboot
After reflashing the eMMC, boot is no longer on loop, and I am able to log in via Console JTAG. However, I cant seem to ssh into the device of ethernet or SFP. I get the following error in boot… \[FAILED\] Failed to start File System Check on Root Device. See 'systemctl status systemd-fsck-root.service' for details. I am currently trying to flash the x410 with the default x410 FPGA image, but the host computer can not detect uhd devices currently. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: x410 stuck in reboot
I was eventually able to resolve the “\[FAILED\] Failed to start File System Check on Root Device.” using fsck tools. I still am not able to ssh into the x410 however. The addresses to not automatically change to the default values(i.e sfp0 = 192.168.10.2), and manually changing them does not appear to work either. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: x410 stuck in reboot
On 14/11/2023 17:40, jmalo...@umass.edu wrote: I was eventually able to resolve the “[FAILED] Failed to start File System Check on Root Device.” using fsck tools. I still am not able to ssh into the x410 however. The addresses to not automatically change to the default values(i.e sfp0 = 192.168.10.2), and manually changing them does not appear to work either. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com The management console of the X410 (if it's like others of its type) uses DHCP by default, and you'll have to figure out what address to use based on that. If it's like other similar devices (I don't have one in my collection yet), you cannot SSH in via the SFP ports--they are strictly for data streaming, and certainly not for mundane tasks like SSH management. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
