usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Ali G. Dezfuli]

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
SSUSUS[WARNING]
TX error detected! Repeating current iteration
SSU[WARNING]
TX error detected! Repeating current iteration
SS[WARNING]
TX error detected! Repeating current iteration
SSS[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

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Marcus D. Leech]

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
SSUSUS[WARNING] 
TX error detected! Repeating current iteration
SSU[WARNING] 
TX error detected! Repeating current iteration
SS[WARNING] 
TX error detected! Repeating current iteration
SSS[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?

Re: phase measurement

[Daniel Estévez]

Hi Karen,

Good you got this working.

I now see that something I said is wrong. I said: to get FFT bin 128, we 
should use Skip Head 127. This is not correct. We need to skip FFT bins 
0 through 127 (both included), which is a total of 128 samples, so we 
should use Skip Head 128.


There is another thing I was misunderstanding. The Keep 1 in N block 
keeps the last element out of every N, rather than the first element of 
every N, which is what I expected. This explains why you need to use 
Skip Head 129 rather than Skip Head 129 as the above paragraph would 
seem to indicate.


Since I find this a bit confusing, I prefer to use the Keep M in N 
block, which keeps the first M elements out of every N, starting with an 
initial offset. I find it more straightforward to think in terms of 
keeping the first element than in terms of keeping the last element. 
Here, using M = 1, N = 1024, and an initial offset of 128 will get you 
the FFT bin you want.


Best,
Daniel.

On 28/12/2022 16:31, Karen young wrote:

Hi Daniel,

Thanks a lot. This is so helpful. I tried both methods you suggested. 
The phase is correct now.


For "Shift: No", compared to the Skip Head value 127,  value 129 has the 
max magnitude. I guess it is a zero-based system. Please correct me if 
wrong.


Thanks and best regards
Karen



On Tue, Dec 27, 2022 at 12:42 PM Daniel Estévez > wrote:


On 27/12/2022 17:49, Karen young wrote:
 > Hi,
 > Attached is the model I built for phase measurement.
 > Since the samp_rate (5M) is 8 times of signal source freq
(625k),  the
 > phase should be expected as shown in the table, while the
measured phase
 > is only correct when there is half cycle or full cycle delay.
 > What can I do to make it correct?
 > Delay step    Expected phase delay    Measured phase delay
 > 0     0       0
 > 1     -0.79   -1.5
 > 2     -1.57   -4.7
 > 3     -2.36   -1.5
 > 4     -3.14   -3.14
 > 5     -3.93   -1.57
 > 6     -4.71   -1.57
 > 7     -5.5    -1.57
 > 8     0       0

Hi Karen,

I think that the problem might be with your Skip Head block. I see that,
in combination with the Keep 1 in N block, you're using it to select the
correct FFT bin in the vectors output by the FFT blocks. However, it
seems to me that you're not selecting the correct bin.

Since you're using "Shift: Yes" in your FFTs, the DC bin would be at
index 512. The bin corresponding to the positive frequency of the cosine
(you're using a real cosine, so it has a positive and a negative
frequency component, if that makes sense), would be at index 512 +
1024/8 = 640. Therefore, I think it's necessary to use 639 as the number
of items to skip.

If you used "Shift: No" in the FFTs, the the positive frequency of the
cosine would be at index 1024/8 = 128, so the number of items to skip
should be 127 rather than 129.

To make sure that you're selecting the correct FFT bin, I suggest you
look at its magnitude and compare it with a plot of the magnitudes of
all the FFT bins. This will show if you're in fact selecting the correct
bin where the maximum of the FFT is, or something else.

Best,
Daniel.






OpenPGP_signature
Description: OpenPGP digital signature

Re: phase measurement

[Karen young]

Hi Daniel,

Thank you so much for all the info, very useful.
I tried the Keep M in N block, straightforward and works great! Now I also
prefer using this block.

Thanks again
Karen

On Wed, Dec 28, 2022 at 2:39 PM Daniel Estévez  wrote:

> Hi Karen,
>
> Good you got this working.
>
> I now see that something I said is wrong. I said: to get FFT bin 128, we
> should use Skip Head 127. This is not correct. We need to skip FFT bins
> 0 through 127 (both included), which is a total of 128 samples, so we
> should use Skip Head 128.
>
> There is another thing I was misunderstanding. The Keep 1 in N block
> keeps the last element out of every N, rather than the first element of
> every N, which is what I expected. This explains why you need to use
> Skip Head 129 rather than Skip Head 129 as the above paragraph would
> seem to indicate.
>
> Since I find this a bit confusing, I prefer to use the Keep M in N
> block, which keeps the first M elements out of every N, starting with an
> initial offset. I find it more straightforward to think in terms of
> keeping the first element than in terms of keeping the last element.
> Here, using M = 1, N = 1024, and an initial offset of 128 will get you
> the FFT bin you want.
>
> Best,
> Daniel.
>
> On 28/12/2022 16:31, Karen young wrote:
> > Hi Daniel,
> >
> > Thanks a lot. This is so helpful. I tried both methods you suggested.
> > The phase is correct now.
> >
> > For "Shift: No", compared to the Skip Head value 127,  value 129 has the
> > max magnitude. I guess it is a zero-based system. Please correct me if
> > wrong.
> >
> > Thanks and best regards
> > Karen
> >
> >
> >
> > On Tue, Dec 27, 2022 at 12:42 PM Daniel Estévez  > > wrote:
> >
> > On 27/12/2022 17:49, Karen young wrote:
> >  > Hi,
> >  > Attached is the model I built for phase measurement.
> >  > Since the samp_rate (5M) is 8 times of signal source freq
> > (625k),  the
> >  > phase should be expected as shown in the table, while the
> > measured phase
> >  > is only correct when there is half cycle or full cycle delay.
> >  > What can I do to make it correct?
> >  > Delay stepExpected phase delayMeasured phase delay
> >  > 0 0   0
> >  > 1 -0.79   -1.5
> >  > 2 -1.57   -4.7
> >  > 3 -2.36   -1.5
> >  > 4 -3.14   -3.14
> >  > 5 -3.93   -1.57
> >  > 6 -4.71   -1.57
> >  > 7 -5.5-1.57
> >  > 8 0   0
> >
> > Hi Karen,
> >
> > I think that the problem might be with your Skip Head block. I see
> that,
> > in combination with the Keep 1 in N block, you're using it to select
> the
> > correct FFT bin in the vectors output by the FFT blocks. However, it
> > seems to me that you're not selecting the correct bin.
> >
> > Since you're using "Shift: Yes" in your FFTs, the DC bin would be at
> > index 512. The bin corresponding to the positive frequency of the
> cosine
> > (you're using a real cosine, so it has a positive and a negative
> > frequency component, if that makes sense), would be at index 512 +
> > 1024/8 = 640. Therefore, I think it's necessary to use 639 as the
> number
> > of items to skip.
> >
> > If you used "Shift: No" in the FFTs, the the positive frequency of
> the
> > cosine would be at index 1024/8 = 128, so the number of items to skip
> > should be 127 rather than 129.
> >
> > To make sure that you're selecting the correct FFT bin, I suggest you
> > look at its magnitude and compare it with a plot of the magnitudes of
> > all the FFT bins. This will show if you're in fact selecting the
> correct
> > bin where the maximum of the FFT is, or something else.
> >
> > Best,
> > Daniel.
> >
> >
>
>

sndfile::sndfile again

[Larry Doolittle]

gnuradio gurus -

I just hit a problem with symptoms that precisely match
https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00055.html

This is while attempting to build gr-osmosdr, basically the first
real step in the instructions at
https://wiki.recessim.com/view/Gr-smart_meters_Setup_Guide

I read Chris Gorman's patch, and it makes sense, but I couldn't find
a way to apply it to my situation.  I'm (attempting to) use gnuradio 3.10.4.0
as supplied in Debian testing (bookworm).  I couldn't find a CMakeLists.txt
file in that gnuradio install that mentions sndfile.

My closest hit was /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindSNDFILE.cmake
which I don't really understand.  I tried hacking on it anyway, but never
found a change that fixed my problem.

Any hints or ideas?  Am I stuck installing gnuradio from source?
Should I file a Debian bug report?

  - Larry

Re: sndfile::sndfile again

[Cinaed Simson]

Hi Larry - try

  apt install libsndfile1-dev

If it installs, blow away the build directory and try to build it again.

Since you installed gnuradio form Debian, you can always install 
gr-osmosdr from Debian and it will match your gnuradio install.


And just to be clear, you need to install gnuradio before you install 
gr-osmosdr.


-- Cinaed


On 12/28/22 14:15, Larry Doolittle wrote:

gnuradio gurus -

I just hit a problem with symptoms that precisely match
https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00055.html

This is while attempting to build gr-osmosdr, basically the first
real step in the instructions at
https://wiki.recessim.com/view/Gr-smart_meters_Setup_Guide

I read Chris Gorman's patch, and it makes sense, but I couldn't find
a way to apply it to my situation.  I'm (attempting to) use gnuradio 3.10.4.0
as supplied in Debian testing (bookworm).  I couldn't find a CMakeLists.txt
file in that gnuradio install that mentions sndfile.

My closest hit was /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindSNDFILE.cmake
which I don't really understand.  I tried hacking on it anyway, but never
found a change that fixed my problem.

Any hints or ideas?  Am I stuck installing gnuradio from source?
Should I file a Debian bug report?

   - Larry

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Ali G. Dezfuli]

thanks Marcus,
I have checked benchmark_rate with no lost packets even at the highest rate
of 25 Ms/s.
It is connected via ethernet 1G.

Isn't it because of outdated firmware and fpga?


the output of benchmark_rate:

$ ./benchmark_rate --rx_rate 25e6

[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
UHD_4.3.0.0-14-g1e718d9b
[00:00:00.000444] Creating the usrp device with: ...
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N200r4
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: WBXv3 RX+GDB
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: WBXv3 TX+GDB

[00:00:01.466484658] Setting device timestamp to 0...
[00:00:01.467214590] Testing receive rate 25.00 Msps on 1 channels
[00:00:11.467783232] Benchmark complete.


Benchmark rate summary:
  Num received samples: 249982026
  Num dropped samples:  0
  Num overruns detected:0
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0


Done!

On Thu, Dec 29, 2022 at 8:04 AM Ali G. Dezfuli  wrote:

> thanks Marcus,
> I have checked benchmark_rate with no lost packets even at the highest
> rate of 25 Ms/s.
> It is connected via ethernet 1G.
>
> Isn't it because of outdated firmware and fpga?
>
>
> the output of benchmark_rate:
>
> $ ./benchmark_rate --rx_rate 25e6
>
> [INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
> UHD_4.3.0.0-14-g1e718d9b
> [00:00:00.000444] Creating the usrp device with: ...
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> Using Device: Single USRP:
>   Device: USRP2 / N-Series Device
>   Mboard 0: N200r4
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: WBXv3 RX+GDB
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: WBXv3 TX+GDB
>
> [00:00:01.466484658] Setting device timestamp to 0...
> [00:00:01.467214590] Testing receive rate 25.00 Msps on 1 channels
> [00:00:11.467783232] Benchmark complete.
>
>
> Benchmark rate summary:
>   Num received samples: 249982026
>   Num dropped samples:  0
>   Num overruns detected:0
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 0
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
>
>
> Done!
>
> On Wed, Dec 28, 2022 at 7:00 PM Marcus D. Leech 
> wrote:
>
>> 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
>> >
>> SSUSUS[WARNING]
>>
>> > TX error detected! Repeating current iteration
>> >
>> SSU[WARNING]
>>
>> > TX error detected! Repeating current iteration
>> >
>> SS[WARNING]
>>
>> > TX error detected! Repeating current iteration
>> > SSS[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

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Marcus D. Leech]

On 28/12/2022 23:35, Ali G. Dezfuli wrote:

thanks Marcus,
I have checked benchmark_rate with no lost packets even at the highest 
rate of 25 Ms/s.

It is connected via ethernet 1G.

Isn't it because of outdated firmware and fpga?

If the FPGA code is out-of-date, UHD will complain.

What does

uhd_usrp_probe    have to say about it.





the output of benchmark_rate:

$ ./benchmark_rate --rx_rate 25e6

[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; 
UHD_4.3.0.0-14-g1e718d9b

[00:00:00.000444] Creating the usrp device with: ...
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N200r4
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: WBXv3 RX+GDB
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: WBXv3 TX+GDB

[00:00:01.466484658] Setting device timestamp to 0...
[00:00:01.467214590] Testing receive rate 25.00 Msps on 1 channels
[00:00:11.467783232] Benchmark complete.


Benchmark rate summary:
  Num received samples:     249982026
  Num dropped samples:      0
  Num overruns detected:    0
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:        0
  Num timeouts (Tx):        0
  Num timeouts (Rx):        0


Done!

On Thu, Dec 29, 2022 at 8:04 AM Ali G. Dezfuli  wrote:

thanks Marcus,
I have checked benchmark_rate with no lost packets even at the
highest rate of 25 Ms/s.
It is connected via ethernet 1G.

Isn't it because of outdated firmware and fpga?


the output of benchmark_rate:

$ ./benchmark_rate --rx_rate 25e6

[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
UHD_4.3.0.0-14-g1e718d9b
[00:00:00.000444] Creating the usrp device with: ...
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N200r4
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: WBXv3 RX+GDB
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: WBXv3 TX+GDB

[00:00:01.466484658] Setting device timestamp to 0...
[00:00:01.467214590] Testing receive rate 25.00 Msps on 1 channels
[00:00:11.467783232] Benchmark complete.


Benchmark rate summary:
  Num received samples:     249982026
  Num dropped samples:      0
  Num overruns detected:    0
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:        0
  Num timeouts (Tx):        0
  Num timeouts (Rx):        0


Done!

On Wed, Dec 28, 2022 at 7:00 PM Marcus D. Leech
 wrote:

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
>

SSUSUS[WARNING]

> TX error detected! Repeating current iteration
>

SSU[WARNING]

> TX error detected! Repeating current iteration
>

SS[WARNING]

> TX error detected! Repeating current iteration
> SSS[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
> [WAR

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Ali G. Dezfuli]

seems it's ok:

$ uhd_usrp_probe
[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
  _
 /
|   Device: USRP2 / N-Series Device
| _
|/
|   |   Mboard: N200r4
|   |   hardware: 2576
|   |   mac-addr: 00:80:2f:0a:ce:45
|   |   ip-addr: 192.168.20.2
|   |   subnet: 255.255.255.255
|   |   gateway: 255.255.255.255
|   |   gpsdo: none
|   |   serial: F1700B
|   |   name: ali_01
|   |   FW Version: 12.4
|   |   FPGA Version: 11.1
|   |
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: WBX v3, WBX v3 + Simple GDB (0x0057)
|   |   |   Serial: EDR29PFXW
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: WBXv3 RX+GDB
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p44
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -200.000 to 200.000 MHz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: WBX v3 (0x0056)
|   |   |   Serial: EDR29PFXW
|   |   |   ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple GDB,
WBX-120 + Simple GDB (0x004f)
|   |   |   Serial: EDR29PFGS
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: WBXv3 TX+GDB
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.0 step 1.0 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: ad9777
|   |   |   |   Gain Elements: None



On Thu, Dec 29, 2022 at 8:17 AM Marcus D. Leech 
wrote:

> On 28/12/2022 23:35, Ali G. Dezfuli wrote:
>
> thanks Marcus,
> I have checked benchmark_rate with no lost packets even at the highest
> rate of 25 Ms/s.
> It is connected via ethernet 1G.
>
> Isn't it because of outdated firmware and fpga?
>
> If the FPGA code is out-of-date, UHD will complain.
>
> What does
>
> uhd_usrp_probehave to say about it.
>
>
>
>
> the output of benchmark_rate:
>
> $ ./benchmark_rate --rx_rate 25e6
>
> [INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
> UHD_4.3.0.0-14-g1e718d9b
> [00:00:00.000444] Creating the usrp device with: ...
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> Using Device: Single USRP:
>   Device: USRP2 / N-Series Device
>   Mboard 0: N200r4
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: WBXv3 RX+GDB
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: WBXv3 TX+GDB
>
> [00:00:01.466484658] Setting device timestamp to 0...
> [00:00:01.467214590] Testing receive rate 25.00 Msps on 1 channels
> [00:00:11.467783232] Benchmark complete.
>
>
> Benchmark rate summary:
>   Num received samples: 249982026
>   Num dropped samples:  0
>   Num overruns detected:0
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 0
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
>
>
> Done!
>
> On Thu, Dec 29, 2022 at 8:04 AM Ali G. Dezfuli  wrote:
>
>> thanks Marcus,
>> I have checked benchmark_rate with no lost packets even at the highest
>> rate of 25 M

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Marcus D. Leech]

On 28/12/2022 23:55, Ali G. Dezfuli wrote:

seems it's ok:

$ uhd_usrp_probe
[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
  _
 /
|       Device: USRP2 / N-Series Device
|     _
|    /
|   |       Mboard: N200r4
|   |   hardware: 2576
|   |   mac-addr: 00:80:2f:0a:ce:45
|   |   ip-addr: 192.168.20.2
|   |   subnet: 255.255.255.255
|   |   gateway: 255.255.255.255
|   |   gpsdo: none
|   |   serial: F1700B
|   |   name: ali_01
|   |   FW Version: 12.4
|   |   FPGA Version: 11.1
|   |
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked
|   | _
|   |    /
|   |   |       RX DSP: 0
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |    /
|   |   |       RX DSP: 1
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |    /
|   |   |       RX Dboard: A
|   |   |   ID: WBX v3, WBX v3 + Simple GDB (0x0057)
|   |   |   Serial: EDR29PFXW
|   |   | _
|   |   |    /
|   |   |   |       RX Frontend: 0
|   |   |   |   Name: WBXv3 RX+GDB
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |    /
|   |   |   |       RX Codec: A
|   |   |   |   Name: ads62p44
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB
|   | _
|   |    /
|   |   |       TX DSP: 0
|   |   |
|   |   |   Freq range: -200.000 to 200.000 MHz
|   | _
|   |    /
|   |   |       TX Dboard: A
|   |   |   ID: WBX v3 (0x0056)
|   |   |   Serial: EDR29PFXW
|   |   |   ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple 
GDB, WBX-120 + Simple GDB (0x004f)

|   |   |   Serial: EDR29PFGS
|   |   | _
|   |   |    /
|   |   |   |       TX Frontend: 0
|   |   |   |   Name: WBXv3 TX+GDB
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.0 step 1.0 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |    /
|   |   |   |       TX Codec: A
|   |   |   |   Name: ad9777
|   |   |   |   Gain Elements: None

You might try backing-out to UHD 4.2 or even UHD 4.1.0.5 (which is what 
is packaged with Ubuntu 22.04).


I recall (haven't found the thread on usrp-users yet) that there was a 
problem with the _cal utilities in UHD 4.3.


I'd recommend that you join the usrp-users mailng list, where more 
USRP-specific discussions take place.

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Ali G. Dezfuli]

Ok, thanks!
You are a great help!

On Thu, Dec 29, 2022 at 8:33 AM Marcus D. Leech 
wrote:

> On 28/12/2022 23:55, Ali G. Dezfuli wrote:
> > seems it's ok:
> >
> > $ uhd_usrp_probe
> > [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
> >   _
> >  /
> > |   Device: USRP2 / N-Series Device
> > | _
> > |/
> > |   |   Mboard: N200r4
> > |   |   hardware: 2576
> > |   |   mac-addr: 00:80:2f:0a:ce:45
> > |   |   ip-addr: 192.168.20.2
> > |   |   subnet: 255.255.255.255
> > |   |   gateway: 255.255.255.255
> > |   |   gpsdo: none
> > |   |   serial: F1700B
> > |   |   name: ali_01
> > |   |   FW Version: 12.4
> > |   |   FPGA Version: 11.1
> > |   |
> > |   |   Time sources:  none, external, _external_, mimo
> > |   |   Clock sources: internal, external, mimo
> > |   |   Sensors: mimo_locked, ref_locked
> > |   | _
> > |   |/
> > |   |   |   RX DSP: 0
> > |   |   |
> > |   |   |   Freq range: -50.000 to 50.000 MHz
> > |   | _
> > |   |/
> > |   |   |   RX DSP: 1
> > |   |   |
> > |   |   |   Freq range: -50.000 to 50.000 MHz
> > |   | _
> > |   |/
> > |   |   |   RX Dboard: A
> > |   |   |   ID: WBX v3, WBX v3 + Simple GDB (0x0057)
> > |   |   |   Serial: EDR29PFXW
> > |   |   | _
> > |   |   |/
> > |   |   |   |   RX Frontend: 0
> > |   |   |   |   Name: WBXv3 RX+GDB
> > |   |   |   |   Antennas: TX/RX, RX2, CAL
> > |   |   |   |   Sensors: lo_locked
> > |   |   |   |   Freq range: 68.750 to 2200.000 MHz
> > |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> > |   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
> > |   |   |   |   Connection Type: IQ
> > |   |   |   |   Uses LO offset: No
> > |   |   | _
> > |   |   |/
> > |   |   |   |   RX Codec: A
> > |   |   |   |   Name: ads62p44
> > |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> > |   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB
> > |   | _
> > |   |/
> > |   |   |   TX DSP: 0
> > |   |   |
> > |   |   |   Freq range: -200.000 to 200.000 MHz
> > |   | _
> > |   |/
> > |   |   |   TX Dboard: A
> > |   |   |   ID: WBX v3 (0x0056)
> > |   |   |   Serial: EDR29PFXW
> > |   |   |   ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple
> > GDB, WBX-120 + Simple GDB (0x004f)
> > |   |   |   Serial: EDR29PFGS
> > |   |   | _
> > |   |   |/
> > |   |   |   |   TX Frontend: 0
> > |   |   |   |   Name: WBXv3 TX+GDB
> > |   |   |   |   Antennas: TX/RX, CAL
> > |   |   |   |   Sensors: lo_locked
> > |   |   |   |   Freq range: 68.750 to 2200.000 MHz
> > |   |   |   |   Gain range PGA0: 0.0 to 31.0 step 1.0 dB
> > |   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
> > |   |   |   |   Connection Type: IQ
> > |   |   |   |   Uses LO offset: No
> > |   |   | _
> > |   |   |/
> > |   |   |   |   TX Codec: A
> > |   |   |   |   Name: ad9777
> > |   |   |   |   Gain Elements: None
> >
> You might try backing-out to UHD 4.2 or even UHD 4.1.0.5 (which is what
> is packaged with Ubuntu 22.04).
>
> I recall (haven't found the thread on usrp-users yet) that there was a
> problem with the _cal utilities in UHD 4.3.
>
> I'd recommend that you join the usrp-users mailng list, where more
> USRP-specific discussions take place.
>
>
>