That's an interesting question, Dan. You seek a low cost oscillator that
follows GPS without following it too closely.
Do you have a plot of a typical day of GPS atmospheric disturbance?
On Mar 8, 2019 2:55 PM, Dan Werthimer wrote:
hi robert, randall, dale and casperites,
thanks for your
In my defence, <100ns is also <100us :)
On Fri, 8 Mar 2019, 2:54 pm Dan Werthimer, wrote:
>
> hi franko:
>
> i think jack meant "<100ns" in his email below. (not "<100us").
>
> here's another description of the technique used in casper instruments to
> get accurate time stamps:
> from peter
Here is a link to an Analog Devices Ap note discussing an accurate timing
reference. It may be a good reference to help you.
https://www.analog.com/media/en/technical-documentation/application-notes/AN-1002.pdf
Bob Stricklin
On Mar 8, 2019, at 8:04 PM, John Ford
mailto:jmfor...@gmail.com>>
Hi Dan, all.
How about a combination of these techniques? You could get an ultra-stable
oscillator, possibly similar to what Bob Jarnot suggested, and then use the
day-old-postprocessed GPS timing results to calibrate the 2 atomic clocks'
time at different places on the earth. Hopefully (to be
hi franko:
i think jack meant "<100ns" in his email below. (not "<100us").
here's another description of the technique used in casper instruments to
get accurate time stamps:
from peter mcmahon's thesis, section C.5:
https://arxiv.org/pdf/1109.0416.pdf
C.5 Precise Timing using ARM and 1PPS
Hi Franco,
The general principle is generally this --
We assume that the system has
1. A CPU-based control computer (a laptop / desktop / posh server /
whatever) which has a standard NTP client running. NTP allows this computer
to know the time good to some number of milliseconds.
2. FPGAs in
Hi John,
Thank you for the answer. I see, so reading the network packages directly
from FPGA using the GBE core, would be the way to go if using PTP or NTP.
Thanks,
Franco
On Thu, Mar 7, 2019 at 10:11 AM John Ford wrote:
> Hi Franco.
>
> We have normally time-stamped the data using a
Hi James,
Thank you for your answer. Yes, I use and ADC for data acquisition. I
understand the general idea of your system. What I don't understand is
where you get the start time of the ROACH2. Is generated by the TRF? Is
there a different system that initialize all the synchronized devices and
Hi SKARAB casperites,
I wanted to add to Jason's question below:
>With the latest libraries, I understand that we should now be able to
compile with that ADC as part of the normal CASPER 'flow. So it should be
>trivial to port CASPER Tutorial #3 (simple spectrometer) to the SKARAB
platform. That
Hi Heystek,
>From an FPGA designers view: it means the gpio FPGA pin you have selected
is not compatible with 3.3 LVCMOS. Your pin looks single-ended, but maybe
you are using a differential pin and it expects a differential IO standard?
Maybe select another gpio pin that you know to be single
Hey Franco and Jack
I have cheked that I have done the post install "fixes"
I have traced the error to these:
ERROR:NgdBuild:488 - Attribute value "LVCMOS33" is not an accepted value for
attribute "IOSTANDARD" on "r2wb640mhz_roach_gpio_a_enable_not_ext<0>".
ERROR:NgdBuild:488 - Attribute
11 matches
Mail list logo
