Thanks for the feedback. I tried 3.13.0.2 this afternoon but still the same Rx
timeout issues.
I’ll take a look at allocating more memory for the ethernet drivers. But the
wireshark results still puzzle me. I’m getting timeouts even on low bandwidth
collects (just as a test case of course).
Here is my Lab's N310 experiance:
3.12 had your issue (2)
3.13.0.0 had bizarre TX behavior and lock ups that required a reboot or
re-image. Our RX noise floor was also suspiciously high.
3.13.0.1 was no better
3.13.0.2 fixed all our problems. As long as we tell linux to allocate
plenty of ram
This message is a continuation of the thread that Rob Kossler last added to
regarding the timeouts on Rx for the N310 when using version 3.13 of the UHD.
Note that we have not tested our X310s with this version - version 3.10 of the
UHD works well with our system of X310s and we don't see a
On Tue, Sep 4, 2018 at 6:55 PM Ashish Chaudhari
wrote:
> On Tue, Sep 4, 2018 at 8:07 AM, Brian Padalino via USRP-users
> wrote:
> > Recently there was a significant change to the noc_block_vector_iir
> > (specifically the vector_iir):
> >
> >
> >
>
On Tue, Sep 4, 2018 at 8:07 AM, Brian Padalino via USRP-users
wrote:
> Recently there was a significant change to the noc_block_vector_iir
> (specifically the vector_iir):
>
>
>
Today, I confirmed that this issue exists on the head of 3.13 and 3.12, but
not 3.11. The example program provided with my previous post can be
compiled with any of these versions.
Rob
On Fri, Aug 31, 2018 at 12:33 PM Rob Kossler wrote:
> In this post and one other post, I mentioned two
On Fri, Feb 09, 2018 at 12:44:26PM -0500, Dang tien Vo-Huu wrote:
>Hi Martin,
>I am on branch rfnoc-devel at version
>b0890fa97ef3dc7d90ed8047d678ca280c72ad61, and I am using Vivado 2015.4
>-
>
On Fri, Aug 17, 2018 at 01:02:28PM -0400, Daryl Lee via USRP-users wrote:
> In November of 2016, I cross-compiled UHD (git-cloned) on my Ubuntu 16.04
> development host targeting a Zynq chip with Linux built with Petalinux
> 2016.3. Life has passed me by and now I need to re-build the library
On Fri, Aug 17, 2018 at 03:53:56PM -0700, Andrew Danowitz via USRP-users wrote:
> Hi,
> I generated an rfnoc fpga image using the latest UHD-fpga tools on the
> rfnoc-devel branch. When I go to run it with the latest UHD on the
> rfnoc-devel branch, I get RuntimeError: RuntimeError: FPGA component
On Fri, Aug 31, 2018 at 10:14:27AM -0400, Marcus D. Leech via USRP-users wrote:
> On 08/31/2018 09:26 AM, Flo A. via USRP-users wrote:
> >Hei!
> >
> >I have a very general question regarding the function of the digital mixer
> >as part of the USRP motherboard-DDC:
> >
> >Since the RF signal is
On Mon, Sep 03, 2018 at 11:39:56AM +, Peng Wang via USRP-users wrote:
>Hi all,
>
>I have couple of USRP X310 and also the PCIe connectivity kit. However, I
>found that the driver [1] says that it can only support up to kernel
>version 4.2.x. Since I am using ubuntu 18.04 with
On 09/03/2018 08:21 PM, Chintan Patel via USRP-users wrote:
> Hello,
>
> I have defined a new readback register in the FPGA in the b205_core
> file, adjacent to the lock state register. What is the least invasive
> function call/method in the UHD driver/software to be able to read this
> newly
On 09/03/2018 07:50 PM, Marcus D. Leech via USRP-users wrote:
> On 09/03/2018 12:15 AM, Marcus D. Leech via USRP-users wrote:
>> On 09/03/2018 12:11 AM, RizThon wrote:
>>> Thanks, I'll try to run it on some intel hardware ("Ettus Research
>>> recommends using the Intel Series 7, 8, and 9 USB
On 09/04/2018 02:10 PM, Jeremy Foran wrote:
*@Brian*
what format should this data be in? Is there a common file type for
this kind of trouble shooting?
*@Marcus*
In terms of my intentions, I would like to same 20Mhz of spectrum
(88Hmz-108Mhz) at a rate of ~20Mhz, the RF team has told me
@Brian
what format should this data be in? Is there a common file type for this kind
of trouble shooting?
@Marcus
In terms of my intentions, I would like to same 20Mhz of spectrum
(88Hmz-108Mhz) at a rate of ~20Mhz, the RF team has told me that should be
enough to test the quality of various
It's true that uhd_image_builder.py will pull in all RFNOC IPs
automatically, but if you go to simulate an OOT rfnoc block that relies on
an IP, in my experience, you have to launch Vivado and add the UHD IP
directory to your project.
On Mon, Sep 3, 2018 at 8:43 PM, Jon Pendlum via USRP-users <
On 09/04/2018 10:56 AM, Jeremy Foran via USRP-users wrote:
Hello All,
I'm new to the community and excited to be a part of it.
I am looking to capture the full FM spectrum for a couple of seconds,
88Mhz to 108Mhz, using the examples supplied by Ettus. I seem to be
getting more zeros in the
On Tue, Sep 4, 2018 at 11:28 AM Jeremy Foran via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Thanks Fabian,
>
> I have tried a few different values for timeout as per your recommendation
> and none seem to have an affect:
> 2.0
> 1.0
> 0.5
> 0.25
> 0.001
>
> All have about the same result
Hi David,
We would like to debug this off the mailing list. Could you please email us
at supp...@ettus.com with the device's serial number?
Regards,
Nate Temple
On Tue, Sep 4, 2018 at 8:31 AM, David Zamorano Fernández via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi all!
>
> We have
Sadly, I still seem to be having this issue. Running threshold's test bench, I
seem to be seeing it as well. I've attempted to reset all the files I touched
(mostly just debug statements), so I don't know if there is an issue with
threshold, but I don't understand why the fifos are filling up
Hi,
the recv function has a return value which tells you the amount of
samples returned. Usually you use this value to increase your buffer
pointer and continue writing where you stopped.
You should also try to plot the data to see what is happening.
Hope that helps,
Fabian
Am 04.09.2018 um
Hi all!
We have implemented a TDMA receiver using the GPS signal to discipline the
internal clock of the E310 and thus reduce frequency deviations. The system
works fine, but in some cases, frequency drifts appear and the slots start
to be erroneous (wrong CRC). The number of visible satellites
Thanks Fabian,
I have tried a few different values for timeout as per your recommendation and
none seem to have an affect:
2.0
1.0
0.5
0.25
0.001
All have about the same result of ~50% of the samples contain a zero.
Ive also tried setting the sample sizes from fc32 to sc16 with more or less
Hi,
maybe your recv runs frequently into timeout. It is the 4th parameter
which is optional and set to a default value of 0.1 seconds.
Best regards,
Fabian
Am 04.09.2018 um 16:56 schrieb Jeremy Foran via USRP-users:
Hello All,
I'm new to the community and excited to be a part of it.
I am
Recently there was a significant change to the noc_block_vector_iir
(specifically the vector_iir):
https://github.com/EttusResearch/fpga/commit/05ca30fe91330d54dcd005a3af4aeaa0dc26c8f8#diff-4b21f52231ba9f82bf132f633d594187
It's a pretty significant re-write of the block, and this behavior has
Hello All,
I'm new to the community and excited to be a part of it.
I am looking to capture the full FM spectrum for a couple of seconds, 88Mhz to
108Mhz, using the examples supplied by Ettus. I seem to be getting more zeros
in the results then I would have expected. About half of the
On Tue, Sep 4, 2018 at 9:15 AM Jon Pendlum via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hey Steve,
>
> The complex_to_mag_phase 32-bit output is a concatenation: [31:16] phase,
> [15:0] magnitude. There is also complex_to_magphase_int16_int24 if you want
> 24-bit phase, mag. The phase
Will,
I believe that I was told that this capability doesn't presently exist and
that it was not trivial to implement on your own. As an alternative, I had
tossed around the following ideas:
1) having the host PC simply "repeat" the streaming to another IP address
2) placing the processing PC
Hey Steve,
The complex_to_mag_phase 32-bit output is a concatenation: [31:16] phase,
[15:0] magnitude. There is also complex_to_magphase_int16_int24 if you want
24-bit phase, mag. The phase value is in scaled radians. If you want a
different phase precision, you will need to create a new CORDIC
Hi all,
I'm trying to create a "complex-to-phase" by using the arctan within the
Xilinx CORDIC IP.
(Part of a simple fft-->1-in-N-->to-phase scheme).
Quite frankly I am a bit confused with the different bit representations.
According to the Xilinx manual (
If you only need integer decimation, noc_block_ddc should have everything
you need or close to it. Averaging across FFTs can be done with
noc_block_vector_iir. For an example, check out the
flowgraph rfnoc_vector_iir.grc in gr-ettus.
Jonathon
On Tue, Sep 4, 2018 at 3:23 PM Rich Maes wrote:
>
I’d like to add a configurable decimator and some averaging logic to the output
of the FFT. So I’ll be adding some new registers to the control bloc and
verilog, but the overall core will still be very similar.
I’ll take a look at the examples you reference below to see if that gets me
32 matches
Mail list logo
