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
Daniel,
The problem was finally solved. It was from both my software and my hardware
development.
-> in fact in the software I used the set_time_next_pps() call from the device3
object to synchronize the vitatime counter with the PPS signal, but later on I
would also create a rfnoc_streamer
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
fabian,
I have tested your solution, but the get_time_last_pps always gives me the
expect value.
Daniel, On a different point, the issue might be related to timing, here are
some examples of timing related to the DACs. The compilation is successful but
the margin is very low, in the 10 ps
No, it was a 3.3V CMOS variant of that IC. I cannot figure it out as I
would have to take the hardware apart.
Am 27.09.2019 um 09:30 schrieb Daniel Jepson via USRP-users:
Fabian,
I noticed on the SN74LS125A datasheet the minimum input voltage is
4.75V. Is this the correct part that you're
Fabian,
I noticed on the SN74LS125A datasheet the minimum input voltage is 4.75V.
Is this the correct part that you're using?
-Daniel
On Fri, Sep 27, 2019 at 9:27 AM Daniel Jepson
wrote:
> Thanks Fabian. As long as the input PPS is driven by the same RefClk that
> is provided to the X310,
Thanks Fabian. As long as the input PPS is driven by the same RefClk that
is provided to the X310, this system should be ok. You might also consider
driving the PPS on the falling edge of the RefClk to ensure timing is met
at the X310. There are some timing constraints here that might affect
Fabian,
thanks for the suggestion I will try the solution
Daniel, I am using the CDA-2990 device from national instruments
Marcus, Some feedbacks,
- what daughtercards are you using in your X310?
+==> the UBX 10-6000 MHz Rx/Tx (160 MHz)
- what do you mean by "hardware block" --
It is a self build device using a 74LS125D as buffer. The level is 3.3V
digital.
As there were no specifications 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
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
Hi,
I have very similar problem with X310. I am running a C++ application,
so I have a bit more flexibility I guess. After I do the
set_time_unknown_pps to sync to the 1PPS signal, I run the function
get_time_last_pps and it sometimes has an offset of 10ns (it was 5ns for
an old firmware due
On 09/25/2019 05:16 AM, Cherif Diouf via USRP-users wrote:
Hello,
I am working with the X310 USRP. I have two identical custom blocks
feeding the RF frontends.
flowchart
-
HW Block1 -> RF0-TX1 |---<
HW Block2 -> RF1-TX1 |---<
The system is synchronized to an external PPS
Hello,
I am working with the X310 USRP. I have two identical custom blocks feeding the
RF frontends.
flowchart
-
HW Block1 -> RF0-TX1 |---<
HW Block2 -> RF1-TX1 |---<
The system is synchronized to an external PPS reference. The sampling rate is
200 MSps and the signal
13 matches
Mail list logo