date:20190719

[USRP-users] N310 "Bad CHDR or packet fragment" Problem

2019-07-19 Thread 汤飞 via USRP-users

Hi, all,

When benchmarking my N310, I keep getting such [RX FLOW CTRL] errors.
What causes this and how to solve it?

Thanks in advance!

FT


/usr/local/lib/uhd/examples/benchmark_rate  \
>--args 
> "type=n3xx,mgmt_addr=192.168.10.2,addr=192.168.10.2,master_clock_rate=122.88e6"
>  \
>--duration 60 \
>--channels "0" \
>--rx_rate 3.84e6 \
>--rx_subdev "A:0" \
>--tx_rate 3.84e6 \
>--tx_subdev "A:0"

[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
UHD_3.14.1.HEAD-0-gbfb9c1c7
[00:00:00.14] Creating the usrp device with: 
type=n3xx,mgmt_addr=192.168.10.2,addr=192.168.10.2,master_clock_rate=122.88e6...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3182B09,claimed=False,addr=192.168.10.2,master_clock_rate=122.88e6
[INFO] [MPM.PeriphManager] init() called with device args 
`master_clock_rate=122.88e6,time_source=internal,clock_source=internal,mgmt_addr=192.168.10.2,product=n310'.
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
Using Device: Single USRP:
  Device: N300-Series Device
  Mboard 0: ni-n3xx-3182B09
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Magnesium
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Magnesium

[00:00:17.353184] Setting device timestamp to 0...
[00:00:17.412187] Testing receive rate 3.84 Msps on 1 channels
[00:00:17.414164] Receiver error: ERROR_CODE_BAD_PACKET
[[ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or packet 
fragment

[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: Bad CHDR or packet fragment
00:00:17.414180] Unexpected error on recv, continuing...
[00:00:17.514258] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:17.514312] Receiver error: ERROR_CODE_BAD_PACKET
[00:00:17.514317] Unexpected error on recv, continuing...
[ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or packet 
fragment

[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: Bad CHDR or packet fragment
[00:00:17.532991] Testing transmit rate 3.84 Msps on 1 channels
[00:00:17.614329] Receiver error: ERROR_CODE_TIMEOUT, continuing...
[00:00:17.614372] Receiver error: ERROR_CODE_BAD_PACKET
[00:00:17.614377] Unexpected error on recv, continuing...

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: Phase coherency for low RX frequencies

2019-07-19 Thread Sammy Welschen via USRP-users

Thanks for your reply.

I am a bit confused now. Since the LO for this stage is derived from the
sample clock, wouldn't I be in the same situation as if I only shared 10
MHz reference and PPS signals?
Quote from https://files.ettus.com/manual/page_usrp_n3xx.html:

--

Reasons to use an external LO include:
Improving phase alignment: The N310 itself has no way of aligning phase
between channels, and phase will be random between runs. By applying an
external LO, the phase ambiguity is reduced to 180 degrees, produced by a
by-2 divider in the AD9371 transceiver IC.
Improving phase noise: The quality of the onboard LO depends on the
external reference clock, among other things. By providing a custom LO
signal, it is possible to more accurately tune, assuming the externally
generated LO signal is coming from a high-quality oscillator.
--

I would still have a certain fixed phase relation between channels, but
with more fluctuations and a phase difference that changes on every turn on
of the devices (i.e. the same situation as when sharing 10 Mhz and PPS
signals). See for example the plots on pages 24-25 of
https://forums.ni.com/ni/attachments/ni/grp-1008/110/1/Fundamentals%20of%20Phase-Coherent%20RF%20Measurements.pdf
for an illustration of what I mean.

Am Do., 18. Juli 2019 um 19:25 Uhr schrieb Marcus D Leech via USRP-users <
usrp-users@lists.ettus.com>:

>
>
>
> I have just been corrected by one of my colleagues at Ettus.
>>
>> While there is an up conversion stage for frequencies below 450Mhz, the
>> LO for that stage is fixed frequency, and derived from the sample clock and
>> coherent across channels.
>>
>> So there should be no random phase offset among channels even below
>> 450Mhz when LO sharing.
>>
>> This is correct as far as I know. Although I don’t have an N320 in my
>> lab, it uses an up conversion scheme for lower frequencies. That scheme
>> does not participate in the LO sharing.
>>
>> Sent from my iPhone
>>
>>
>> On Jul 18, 2019, at 11:17 AM, Sammy Welschen via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> I have to acquire phase coherent data on multiple channels using USRP
>> N310/320 devices.
>>
>>
>>
>> Am I correct in assuming that for frequencies below 450 MHz, there is no
>> way to remove random phase differences between channels due to the
>> additional frequency shift involved (shown for example in the block
>> diagram
>> http://www.ettus.com/wp-content/uploads/2019/03/N320BlockDiagram.png
>> )?
>> As I understand it, by using the same LO signal for all channels I could
>> remove the differences for frequencies above 450 MHz, but this is of no use
>> for frequencies below 450 MHz due to this the additional stage.
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>>
>> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Detection of USRP X310

2019-07-19 Thread Saimanoj Katta via USRP-users

Hi,

I was previously working with the USRP X310. I wanted to enable Dual
Connectivity mode for enabling two ports with 10 Giga bit connectivity. I
ran the update:  uhd_image_loader --args "type=x300,addr=192.168.50.2,
fpga=XG". Since this, I have not been able to detect my USRP.

*My setup: * Ubuntu is 18.04 and the UHD version is UHD_3.14.1.0-0-gbfb9c1c7
I have connected to the laptop via thunderbolt port which is equivalent to
USB-3.0. Firewall is disabled. It is not behind a router/switch. Host
interface IP address is 192.168.10.3 and subnet is 255.255.255.0

I have tried the following:

1) Ran as root user - uhd_find_devices, uhd_usrp_probe and
uhd_images_downloader.
Device is not found in first two options. And, the fpga_default images seem
to be up to date.
2) By default, USRPs have addresses from the 192.168.10.XXX range (XXX=2 in
factory settings). I searched addresses in this range, but still USRP not
detected. Ping to the address also fails.

Any suggestions would be appreciated to detect the device! Many thanks in
advance.

Regards,
Saimanoj
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: Phase coherency for low RX frequencies

2019-07-19 Thread Marcus D. Leech via USRP-users

On 07/19/2019 05:24 AM, Sammy Welschen via USRP-users wrote:

Thanks for your reply.

I am a bit confused now. Since the LO for this stage is derived from
the sample clock, wouldn't I be in the same situation as if I only
shared 10 MHz reference and PPS signals?

Quote from https://files.ettus.com/manual/page_usrp_n3xx.html:
My understanding was that we were talking about the N320, and only a
single unit?

I need to confirm, but I think the upconverter LO on the N320 is a
single (clock-derived) oscillator, shared among the channels in the
unit. In that case, the
phase relations will be static across powerups, assuming that you
share the other LOs.

In the case of multiple N320s, I don't yet have an answer, since it
depends critically on how that upconverter LO is produced, and how the
external-reference

PLL works.

Reasons to use an external LO include:

Improving phase alignment: The N310 itself has no way of aligning
phase between channels, and phase will be random between runs. By
applying an external LO, the phase ambiguity is reduced to 180
degrees, produced by a by-2 divider in the AD9371 transceiver IC.
Improving phase noise: The quality of the onboard LO depends on the
external reference clock, among other things. By providing a custom LO
signal, it is possible to more accurately tune, assuming the
externally generated LO signal is coming from a high-quality oscillator.

I would still have a certain fixed phase relation between channels,
but with more fluctuations and a phase difference that changes on
every turn on of the devices (i.e. the same situation as when sharing
10 Mhz and PPS signals). See for example the plots on pages 24-25 of
https://forums.ni.com/ni/attachments/ni/grp-1008/110/1/Fundamentals%20of%20Phase-Coherent%20RF%20Measurements.pdf
for an illustration of what I mean.

Am Do., 18. Juli 2019 um 19:25 Uhr schrieb Marcus D Leech via
USRP-users >:

I have just been corrected by one of my colleagues at Ettus.

While there is an up conversion stage for frequencies below
450Mhz, the LO for that stage is fixed frequency, and derived
from the sample clock and coherent across channels.

So there should be no random phase offset among channels even
below 450Mhz when LO sharing.

This is correct as far as I know. Although I don’t have an
N320 in my lab, it uses an up conversion scheme for lower
frequencies. That scheme does not participate in the LO
sharing.

Sent from my iPhone

On Jul 18, 2019, at 11:17 AM, Sammy Welschen via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

I have to acquire phase coherent data on multiple
channels using USRP N310/320 devices.

Am I correct in assuming that for frequencies below 450
MHz, there is no way to remove random phase differences
between channels due to the additional frequency shift
involved (shown for example in the block diagram
http://www.ettus.com/wp-content/uploads/2019/03/N320BlockDiagram.png

)?
As I understand it, by using the same LO signal for all
channels I could remove the differences for frequencies
above 450 MHz, but this is of no use for frequencies
below 450 MHz due to this the additional stage.

___
USRP-users mailing list
USRP-users@lists.ettus.com

http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N310 "Bad CHDR or packet fragment" Problem

Re: [USRP-users] Fwd: Phase coherency for low RX frequencies

[USRP-users] Detection of USRP X310

Re: [USRP-users] Fwd: Phase coherency for low RX frequencies

4 matches

Site Navigation

Mail list logo

Footer information