Martin,
This error is caused by the setup.py file located in the python folder in your
build directory.
Within that file there is a line of code that should look like this (probably
line 26):
package_dir={'': '/python"},
My fix for this, though admittedly inelegant, is to simply comment out
Hi,
I wrote a simple C++ application to test my ability to stream to and from
the SplitStream NoC block (this test was in preparation for subsequently
using a custom block that has 1 input and 2 outputs). The application
works, but it has the behavior that there are a couple of "D"
Hello all,
I am attempting to build the latest 3.13 branch.
I am encountering an error. It seems simple if I knew where to look:
7>Generating build/timestamp
7>CUSTOMBUILD : error : package directory
'C:martin\uhd_stack_build\uhd_build\python\uhd' does not exist
7>Done building project
Ettus Research is proud to announce the USRP E320 software defined radio,
which brings performance to embedded SDR by offering four times more FPGA
resources compared to its predecessor USRP E31x devices. The USRP E320 also
introduces improvements in streaming, synchronization, integration,
Hi all,
Thanks for all of your help. Once I annotated the signals to debug, Vivado
started failing on creating a bitstream. It turns out I had labeled the
wrong direction for the master tready signal which in default synthesis was
driven to 0.
Thanks,
Andrew
On Fri, Dec 21, 2018 at 11:33 AM
On 01/03/2019 02:18 PM, Sivan Toledo wrote:
Seems like we are getting closer.
The code I use to set the time source is
uhd_usrp_set_clock_source(usrp, "external", ALL_MBOARDS);
uhd_usrp_set_time_source(usrp, "_external_", ALL_MBOARDS);
Maybe it should not be _external_ by "external"
Seems like we are getting closer.
The code I use to set the time source is
uhd_usrp_set_clock_source(usrp, "external", ALL_MBOARDS);
uhd_usrp_set_time_source(usrp, "_external_", ALL_MBOARDS);
Maybe it should not be _external_ by "external" without the "_"s? At least
on N200 _external_
On 01/03/2019 05:05 AM, Brais Ares wrote:
I also happen to have some spare B200 devices around and I can confirm
what @Martin stated.
Since we are working in a jitter-sensitive critical application and
after the tests I've perfomed, I'm inclined to think the minimum
jitter scenario occurs
On 01/03/2019 08:53 AM, Sivan Toledo wrote:
Hundreds of milliseconds, which I think imply that either the PPS is
arriving at a random time (not likely), or that the function that sets
the time at the next PPS actually sets it immediately.
The only thing i can think of is a setup error. Like
On 01/03/2019 12:53 PM, Milos Milosavljevic wrote:
No worries Ian. Yeah I have tried different options with
tune_request object (including different lo_offsets) but not much
luck. There are a few quite strong spurs at 10,20 and some at higher
freq but nothing seems to help with reducing the
On 01/03/2019 11:34 AM, Brais Ares wrote:
Hi Marcus,
Theoretically, there'll be analog group delays that will add some
harder-to-predict latency, but they'll be much smaller than the
time interval represented by the timestamps.
Ok, we can consider those analog delays negligible.
No worries Ian. Yeah I have tried different options with tune_request object
(including different lo_offsets) but not much luck. There are a few quite
strong spurs at 10,20 and some at higher freq but nothing seems to help with
reducing the power of those. It looks like we would have to use a
Hi Marcus,
> Theoretically, there'll be analog group delays that will add some
> harder-to-predict latency, but they'll be much smaller than the
> time interval represented by the timestamps.
Ok, we can consider those analog delays negligible. Sorry to insist but, do
I still need to
Milos,
Early AM for me….disregard what I just said…had a pre-coffee moment…LO not
present in signal chain at that point…doh!
> On Jan 3, 2019, at 7:27 AM, Milos Milosavljevic
> wrote:
>
> Thank you Ian.
>
> Apologies, we are using the SBX not WBX (that was a typo from my side). I
> believe
Correct, move the LO greater than 20MHz away from 0Hz to suppress the LO via
the LPF on SBX/WBX.
> On Jan 3, 2019, at 7:27 AM, Milos Milosavljevic
> wrote:
>
> Thank you Ian.
>
> Apologies, we are using the SBX not WBX (that was a typo from my side). I
> believe that SBX also has TX
Thank you Ian.
Apologies, we are using the SBX not WBX (that was a typo from my side). I
believe that SBX also has TX baseband filters.
Regardless, sorry, but what did you mean by offsetting the LO spur's into those
filters? Via tune_request_t?
Thanks
Milos
Milos,
FWIW WBX includes TX baseband filters of 40MHz bandwidth. LO offsetting your LO
spur’s into those should suppress this.
-Ian
> On Jan 3, 2019, at 3:48 AM, Milos Milosavljevic via USRP-users
> wrote:
>
> Thank you Marcus. Much appreciated.
>
> I think I do understand why would I see
Hundreds of milliseconds, which I think imply that either the PPS is
arriving at a random time (not likely), or that the function that sets the
time at the next PPS actually sets it immediately.
Otherwise your assumptions about my setting is correct, an N200 and a B200
each with its own Ettus
Thank you Marcus. Much appreciated.
I think I do understand why would I see some sort of phase noise if DUC doesnt
work but the only one bit of information that i am missing (i am sure it is a
silly question) is why would the offset be ignored if tune_request_t is
typcasted to float? Btw, just
I also happen to have some spare B200 devices around and I can confirm
what @Martin stated.
Since we are working in a jitter-sensitive critical application and after
the tests I've perfomed, I'm inclined to think the minimum jitter scenario
occurs when using the internal reference (2 ppm), given
20 matches
Mail list logo
