Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

On 28/12/2022 04:55, Ali G. Dezfuli wrote:
> Hi all,
> I have gnuradio on this system:
> ubuntu 22.04
> uhd 4.3.0.0-14-g1e718d9b
> gnuradio v3.11.0.0git-316-gc11667ef
>
> I have a USRP N200 from 2011 but have not worked with it for the last
> couple of years.
> After a long while, I just run $ uhd_cal_tx_dc_offset but got the
> following error:
>
> Creating the usrp device with: ,ignore_cal_file=1,ignore-cal-file=1...
> [INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
> UHD_4.3.0.0-14-g1e718d9b
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> Running calibration for WBXv3 TX+GDB
> Daughterboard serial: EDR29PFXW
> Calibration frequency range: 68.75 MHz -> 2200 MHz
> SSUSUSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS[WARNING]
> TX error detected! Repeating current iteration
> SSSSSSSSSSSSSSUSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS[WARNING]
> TX error detected! Repeating current iteration
> SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS[WARNING]
> TX error detected! Repeating current iteration
> SSSSSSSSSSSSSSSSSSS[WARNING] TX error detected! Repeating current
> iteration
> [WARNING] TX error detected! Repeating current iteration
> [WARNING] TX error detected! Repeating current iteration
> [WARNING] TX error detected! Repeating current iteration
> [WARNING] TX error detected! Repeating current iteration
> [WARNING] TX error detected! Repeating current iteration
> [WARNING] TX error detected! Repeating current iteration
> terminate called without an active exception
> Aborted (core dumped)
>
> I would be grateful if somebody helps me with this error.
> regards
> AGD
The occurrence of 'S' signifies a sequence-number error, the underlying
cause of which is usually the network stack.

If you use the "benchmark_rate" example at modest sample-rates, does
this still occur?


How are you connected to the USRP?  What type of network interface do
you have?   Are you running on the native hardware,
  or in a VM?  Have you tried replacing the network cable?