Hi all.

I just unboxed my two new X410. I try to power them on following the procedure in the getting started guide, but they both seem to not turn on.

The green LED on the power supply seems to become weaker when it is attached to the X410 backplane and the power LED does not turn on.

It seems strange because it happens with both devices by trying both power suppliers.

I don’t think is a power network problem because the PXI Chassis that consumes more power works without problems.

I’ve used the X310 before and I had never had such problem.

Thanks in advance,

Arjan

Sorry, no question in the message :).

Had anyone had this kind of issue before?

Thanks,

Arjan

Hi Wade,
Coincidentally I just measured the output voltage of the power supply and found that the three of them wobble around 8 to 9 volts. Thew point is that I have two of them and they do the same thing, which raises the suspicion it is not a coincidence.
I guess I should check that the AC power source is not playing a bad joke on me.
Thank you,

Arjan

Arjan FETA
SDR Engineer
[cid:image001.png@01D98A68.59E21180]http://www.rheagroup.com/
RHEA GROUP
2, Rue d’Arlon, L-8399 Windhof
Office: +32 (0) … | Mobile: +39 3287071042
www.rheagroup.comhttp://t.sidekickopen54.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg2BpyRFW8qStpx3My7xPW2BW4zb56dTT6f5_X-rg02?t=http%3A%2F%2Fwww.rheagroup.com%2F&si=6251671876534272&pi=84d8d6f5-3fd1-4962-9bfd-7b2b225b6306

From: Wade Fife wade.fife@ettus.com
Sent: 19 May 2023 15:35
To: Arjan Feta a.feta@rheagroup.com
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Re: X410 not powering on

You don't often get email from wade.fife@ettus.commailto:wade.fife@ettus.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
Caution: This email was sent from an external source, do not click links or open attachments unless you recognize the sender email address and know the content is safe.

Hi Arjan,

I have not heard of this before. It should be as simple as connecting an appropriate AC cable to the X410 power supply brick, plugging the AC cable into the wall, then plugging the 6-pin power cable into the X410 and pressing the power button. If you haven't already, try disconnecting everything from the X410 itself except the power cable and powering it on. Also try different AC cables (the one that connects the power supply brick to the wall socket). If you have a voltage meter you could also measure the voltage on the power supplies to confirm they're OK. I suggest you contact support@ettus.commailto:support@ettus.com if you can't get it to work.

[cid:image002.png@01D98A68.59E21180]

Wade

On Fri, May 19, 2023 at 2:55 AM Arjan Feta via USRP-users <usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com> wrote:

Sorry, no question in the message :).

Had anyone had this kind of issue before?

Thanks,

Arjan

USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com

Hi,
I installed UHD 4.4 recently. I use USRP for both transmission and receive. I find that EVM in the tail part of the captured signal is higher, e.g., in a 20-slot capture, in the first 19 slots, EVM~= 1.2%, but in slot#20, evm ~=2.9%.
UHD 3.10 was fine. I have found this problem in UHD 4.0 and UHD 4.1. Now it still exists in UHD 4.4. My solution is to capture 1ms more than what I need. 
Is this a bug in FPGA?
Thanks,Hongwei

Thanks Marcus. Yes, I have observed that people are using USRPs for different applications. My application is for gNB simulation for 5G. Slot is a term for signal structure in time domain in physical layer in 5G. Generally, its length is 1ms.
Your guess is correct. I am doing timed capture for an exact number of samples. The transmitter transmits signal endlessly, and the capture is on demand.Now I have to capture 1ms more than what my analysis requires. The 1ms extra signals are discarded in analysis but they did protect the signals I need.It seems that the receiver shut down too early.

On Saturday, 20 May 2023 at 23:14:16 BST, Marcus D. Leech <patchvonbraun@gmail.com> wrote:  

On 20/05/2023 18:03, zhou via USRP-users wrote:

Hi,
I installed UHD 4.4 recently. I use USRP for both transmission and receive. I find that EVM in the tail part of the captured signal is higher, e.g., in a 20-slot capture, in the first 19 slots, EVM~= 1.2%, but in slot#20, evm ~=2.9%.
UHD 3.10 was fine. I have found this problem in UHD 4.0 and UHD 4.1. Now it still exists in UHD 4.4. My solution is to capture 1ms more than what I need. 
Is this a bug in FPGA?
Thanks, Hongwei
Without telling us what you mean by a "slot", and exactly how you're capturing, it's impossible to say.   Remember, applications
  of USRPs are incredibly diverse, so if you're using nomenclature that is specific to your particular work, others may not
  understand what it is you're doing.   Please be more specific.

My guess is that you're doing a timed capture for an exact number of samples, and that timing has become a bit more
  "tight" in more recent releases, so you're capturing samples as the receiver is shutting down, or the transmitter is
  shutting down.

USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com

Hi Marcus,
Sorry for the late response.My system setup: - UHD 4.4- Ubuntu 22.04 server version- USRP: X310

The capture code:uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make("addr=192.168.12.2, second_addr=192.168.13.2, master_clock_rate=184.32e6");uhd::stream_args_t stream_args_rx("sc16", "sc16");stream_args_rx.channels.push_back(0);stream_args_rx.channels.push_back(1);uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args_rx);uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);stream_cmd.num_samps = num_requested_samples;stream_cmd.stream_now = false;stream_cmd.time_spec = uhd::time_spec_t(ul_time_spec);rx_stream->issue_stream_cmd(stream_cmd);size_t num_rx_samps;unsigned long num_total_samps = 0;while(num_requested_samples != num_total_samps){   num_rx_samps = rx_stream->recv(buff, num_requested_samples, md, 5.0);   num_total_samps += num_rx_samps;}
If I capture exactly num_requested_samples, then the final part of the capture will not be good. I have to capture 1ms more. In UHD 3.10, I don't see this problem.

Thanks for any feedback.

On Monday, 22 May 2023 at 01:00:32 BST, Marcus D. Leech <patchvonbraun@gmail.com> wrote:  

On 21/05/2023 18:57, zhou wrote:

Thanks Marcus. Yes, I have observed that people are using USRPs for different applications. My application is for gNB simulation for 5G. Slot is a term for signal structure in time domain in physical layer in 5G. Generally, its length is 1ms.
Your guess is correct. I am doing timed capture for an exact number of samples. The transmitter transmits signal endlessly, and the capture is on demand. Now I have to capture 1ms more than what my analysis requires. The 1ms extra signals are discarded in analysis but they did protect the signals I need. It seems that the receiver shut down too early.

Could you share with us exactly how you're setting up the capture?  What stream arguments are you using, etc?

  On Saturday, 20 May 2023 at 23:14:16 BST, Marcus D. Leech <patchvonbraun@gmail.com> wrote:  

  On 20/05/2023 18:03, zhou via USRP-users wrote:


Hi, 

I installed UHD 4.4 recently. I use USRP for both transmission and receive. I find that EVM in the tail part of the captured signal is higher, e.g., in a 20-slot capture, in the first 19 slots, EVM~= 1.2%, but in slot#20, evm ~=2.9%.
UHD 3.10 was fine. I have found this problem in UHD 4.0 and UHD 4.1. Now it still exists in UHD 4.4. My solution is to capture 1ms more than what I need. 
Is this a bug in FPGA?
Thanks, Hongwei
Without telling us what you mean by a "slot", and exactly how you're capturing, it's impossible to say.   Remember, applications
  of USRPs are incredibly diverse, so if you're using nomenclature that is specific to your particular work, others may not
  understand what it is you're doing.   Please be more specific.

My guess is that you're doing a timed capture for an exact number of samples, and that timing has become a bit more
  "tight" in more recent releases, so you're capturing samples as the receiver is shutting down, or the transmitter is
  shutting down.

_______________________________________________

USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com