Have you disabled usb auto-suspend, turned off all power saving, turned off
frequency scaling?
> On Jul 12, 2021, at 19:22, shachar J. brown wrote:
>
>
> Hi Marcus,
>
> Yes indeed. original cable.
>
> BTW, additional information: Different ports have different durations before
> they cra
What does “dmesg” have to say about it when this happens? There’s usually a
disconnect message with some surrounding context.
Sent from my iPhone
> On Jul 12, 2021, at 3:44 PM, shachar J. brown wrote:
>
>
> Hi Marcus,
>
> Yes indeed. original cable.
>
> BTW, additional information: Differ
Hi Marcus,
Yes indeed. original cable.
BTW, additional information: Different ports have different durations
before they crash.
Specifically, ports on one side survive much longer than the other side.
This holds while the ports share similar color and marking.
BR,
Steve
On Mon, Jul 12, 2021 a
Are you using the Ettus supplied cable?
Controllers will disconnect devices when they sense excess noise on the cable.
Sent from my iPhone
> On Jul 12, 2021, at 3:27 PM, shachar J. brown wrote:
>
>
> Hi Marcus,
>
> Thanks for the reply.
>
> I believe this is not a power problem as the B
Hi Marcus,
Thanks for the reply.
I believe this is not a power problem as the B210 was fed with an external
power.
The problem still thrives, any further suggestions are more than welcomed.
BR,
Steve
On Thu, Jun 24, 2021 at 7:28 PM Marcus D. Leech
wrote:
> On 06/24/2021 02:31 AM, shachar J. b
Hi Ming,
For static coefficients, try setting RELOADABLE_COEFFS = 0 and
USE_EMBEDDED_REGS_COEFFS = 0. I did a quick simulation and it seemed to
work, but I didn't spend much time checking it. Make sure you also set
NUM_COEFFS and COEFFS_VEC correctly where the rfnoc_block_fir_filter is
instantiate
On 07/12/2021 01:31 PM, Arjan Feta wrote:
Helloo Marcus and thank you!
I have already did some tests with the two physical channels, fom TX
to right before the X300 SMA ports, once with: Ch1->RX1, Ch2->RX2; and
then I exchanged to: Ch2->RX1, Ch1->RX2.
The results showed instability with tempera
Helloo Marcus and thank you!
I have already did some tests with the two physical channels, fom TX to
right before the X300 SMA ports, once with: Ch1->RX1, Ch2->RX2; and then I
exchanged to: Ch2->RX1, Ch1->RX2.
The results showed instability with temperature gradients in RX1 only. This
throughs susp
Your query is best asked on the GR discussion list / GR chat rooms:
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio . - MLD
On Sun, Jul 11, 2021 at 5:39 PM wrote:
> I have a couple of questions about the GnuRadio QT GUI Frequency Sink
> Block , which allows you to specify FFT size and u
Hi Vladica - What Rob wrote is correct, and something I've come across in
my WR testing during June: N320/N321 support was added in UHD 3.14, and
thus actual WR functionality has been broken there since release for those
USRPs; testing was done to verify that the WR core on the FPGA was
functional,
On 07/12/2021 11:44 AM, arjan.f...@unifi.it wrote:
Hi all,
I am measuring the power of two signals (sinusoids) through an RMS
calculation, using an TwinRX on a x300 motherboard. In the calibration
process (lab conditions, no noise, no interference) I’m trying to
obtain a differential power (
Hi Marcus,
Thank you for replying back, first of all I want to say that this was a silly
mistake I made, and found it out when I ran the test bench. Because It was a
OOT block, I renamed my previous skeleton of the RFNoC block with a different
name (I wanted to use the same user logic for testi
Hi Vladica,
>From the 'changelog', it appears that N321 support began with release
3.14. But, at that point I believe that WR was already broken. So, I
think that there is no solution to your problem other than to wait for
Ettus to fix the WR issues. However, WR has been broken for a while (note
Hi all,
I am measuring the power of two signals (sinusoids) through an RMS calculation,
using an TwinRX on a x300 motherboard. In the calibration process (lab
conditions, no noise, no interference) I’m trying to obtain a differential
power (p1-p2) of 0dB or at least constant at ±0.5dB . One of
the default X310 image has static connections in between the radio and the
endpoint on the crossbar, so while the dynamic routing of the stream is
still available, the two need to be used as a pair
in the image the layout is like this:
RX->DDC->EP->crossbar
EP->DUC->EP->crossbar
the crossbar isn't
Do you also have a DUC between the radio and streamer?
> On Jul 12, 2021, at 07:41, Cherif Diouf wrote:
>
>
> Hi,
>
> I am using an X310 device and I have freshly install RFNoC 4, (Vivado 2019.1,
> UHD 4.0, GNU Radio 3.8, gr-ettus )using the migration guide
>
> (https://kb.ettus.com/RFN
Hi,
I am using an X310 device and I have freshly install RFNoC 4, (Vivado 2019.1,
UHD 4.0, GNU Radio 3.8, gr-ettus )using the migration guide
(https://kb.ettus.com/RFNoC_4_Migration_Guide#Prerequisites).
I tried to build a simple GNU Radio flowgraph
GNU Radio source signal (cosine) -> RFNoC TX
17 matches
Mail list logo
