Hi David,
Indeed, this sounds like a bug, and I believe you have the correct solution
identified. We will begin validating the fix on our side, but you can try
adding `XQ` to the list here: sfp_time_source_images = ('WX',) and then
recompiling. You should be able to just modify the installed file
Cherif,
Great news! Congrats on the fix!
Cheers,
Daniel
On Mon, Oct 7, 2019 at 9:48 AM Cherif Diouf via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Daniel,
>
>
> The problem was finally solved. It was from both my software and my
> hardware development.
>
> -> in fact in the software I us
Fabian, I had a hunch it was just the 3.3V part--thanks for clarifying!
Cherif, the DAC interface timing (and for that matter, the ADC timing)
should be fairly tight. What you're seeing is expected and matches the
numbers we designed it to. The FPGA constraints are intentionally tight to
provide s
ls at
>> the time we needed the device, we just measured the levels coming from
>> the 1PPS output and replicated them.
>>
>> Am 26.09.2019 um 13:51 schrieb Daniel Jepson via USRP-users:
>> > Hi Fabian, Cherif,
>> >
>> > What is the external
tions around for the required input levels at
> the time we needed the device, we just measured the levels coming from
> the 1PPS output and replicated them.
>
> Am 26.09.2019 um 13:51 schrieb Daniel Jepson via USRP-users:
> > Hi Fabian, Cherif,
> >
> > What is the
Hi Fabian, Cherif,
What is the external PPS device you are using?
-Daniel
On Thu, Sep 26, 2019 at 9:18 AM Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> I have very similar problem with X310. I am running a C++ application,
> so I have a bit more flexibility I gues
Sounds good. I'll allow others to comment on the GNURadio side of things.
Let me know if you have any specific HW concerns and I can chime in.
-Daniel
On Mon, Jul 22, 2019 at 5:17 PM m2wagner via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
>
> Hey Daniel,
>
> Right now I'm setting an exter
Hi Mark,
A few questions: Is your clock recovery algorithm running in the FPGA? Do
you require the sample clock/LOs to be disciplined to this recovered clock?
While the N310 does not have a dedicated clock output port, if the
recovered clock is internal to the FPGA you can transmit a copy of it o
Hi Diogo,
While there are hooks in UHD to support custom reference clock rates, the
majority of the synchronization (PPS and sample clock alignment) routines
rely heavily on known rates (10, 20, 25M). It would be non-trivial to
update everything to use 100M as reference. Let me know if this is a p
Hi Kwansik,
The Octoclock datasheet specification is only valid when driving into a 50
ohm load, and it should be just under 1.4Vpp.
Cheers,
-Daniel
On Thu, Jan 10, 2019 at 7:22 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 01/10/2019 08:07 PM, Kwansik Park via USR
Hi Serge,
Are you measuring the phase offset between the TX0 and TX2 signals in a
steady-state case, or the time difference in the start of those signals?
In the former case, your results could be impacted by the lack of internal
LO sharing between daughterboards. I would fully expect an unknown
ikes me as odd that so many of the "whole number" MHz sample
>>>>> rates are neglected on the n3xx series by default-- it's often the case
>>>>> that I'll want to interact with other hardware with baud rates at, say, 2
>>>>> MHz o
needed, potentially a "quick and dirty" approach might be to
>> make an rfnoc fractional resampler that combines a DUC and DDC into one
>> "ce", with a block controller to calculate the magical conversions... It's
>> not an optimal solution but it might do the
Hi Jean-Michel,
As you hinted, it might be best to re-post this to the White Rabbit list:
https://lists.ohwr.org/sympa/info/white-rabbit-dev
>From my limited experience with White Rabbit and the N310 product, I don't
see any obvious issues, other than possibly within the switch.
-Daniel
On Wed,
Hi EJ,
The fundamental limitation comes from the AD9371. Although the datasheet
specifies a wide reference clock input range, there are only certain
supported rates within the public side of their API (at least that I'm
aware of). These include the rates you mentioned from the KB.
Assuming the AD
All,
A patch for this bug is now included in UHD-3.13. The root cause was a
clock switching routine failing to re-initialize the daughterboard PLLs.
https://github.com/EttusResearch/uhd/tree/UHD-3.13
The specific fix is in 5286f1c.
Cheers,
-Daniel
On Tue, Aug 7, 2018 at 9:36 AM, Rob Kossler w
Rob,
That is indeed strange behavior. The GPSDO for the N310 has changed from
previous products to produce a 20MHz reference instead of 10MHz. Either
way, the PPS should arrive every 20e6 ticks of the reference clock from the
GPSDO, whether it is locked or not. It appears that the PPS is around 8u
Hi Rob,
Thanks for the heads up on the documentation bug. While digging through it
I also noticed a bug in the White Rabbit arguments. WR disciplines the
internal oscillator, so that must be explicitly selected. Below is the
correct clock/time combination to enable WR:
auto usrp =
uhd::usrp::mult
Dmitry,
The PPS and 10MHz should (at the very least) be generated using the same
base clock so they don't drift with respect to one another. Since you are
using multiple X310 devices, it is also important that the PPS arrives at
each device on the exact same cycle of the 10MHz clock--otherwise you
Correct, the master clock rate must be one of those three values. Others
will have to weigh in on the specifics of set/get rx/tx rate.
On Fri, Mar 2, 2018 at 8:43 AM, Андрей 1 wrote:
> When I set the 200 MHz function to set_rx_rate and then I request
> get_rx_rate, then I get 100 MHz.
> What val
Hi,
The X300/X310 supports three Sampling Rates: 120MHz, 184.32MHz, and 200MHz.
Your rate was most likely coerced to the most common rate of 200M. The FPGA
then performs decimation and interpolation such that the host doesn't have
to stream all that bandwidth (nor can it in most cases). The stream
21 matches
Mail list logo
