Hello, We use a different scheme for datation, not using any GPS. Our ROACH2 is bind to a rubidium clock, then: 1/ Each 8K acquisition packet is taged with a 64 bits counter in the FPGA reset only at firmware init. The acquisition is continuous, the dispatching of relevant data is delegated to receiving PCs. 2/ regular records of couples (last received packet, unix time) are stored in an regularly increasing file. Of course a (8Kxsample rate) random is introduce here. This is overcome by a statistical treatment, with a 1.1Gs/s rate you need 64.e6 couples to get the nano second. Important: note here that you need an iterative rejection procedure, as these couples show outlayers. With that care, it appears that NTP is a nice protocol, and residuals folow the anticipated rules. We are then provided, with a self-consistent datation, as long as nor firmware, nor clock are resetted, down to the rubidium specs. How to relate with the actual acquisition TU? Basically the transfer time between ADC/10Gb ethernet receiver is unknown, but likely constant. It has only to be mesured once. We never needed to go down to that precision, so we did not acheive that part of work. A good candidate would have been the observation of a well known pulsar, that would include the whole acquisition process (with the GPS in the FPGA you do not know the upward RF delay). I have no experience of GPS, but only on earlier OMEGA clock system (that was for sysmologists, I hope I made here more clear for astronomers) . I did similar regressions. Daily excursions were clearly visible, but measures during night folowed a regular flat patern. I do not know how GPS overcome these propagation hazards, but anyhow, any method in this field have its physical limits. With our method, the only limit is the local clock characteristics.
Hope this may help Jean Borsenberger Le Lundi, Mars 11, 2019 08:26 CET, James Smith <jsm...@ska.ac.za> a écrit: Hello Franco, Jack's email explained more explicitly what I tried to convey. Did it make it clear? Regards,James On Sat, Mar 9, 2019 at 12:44 AM Jack Hickish <jackhick...@gmail.com> wrote:Hi Franco, The general principle is generally this -- We assume that the system has1. 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 the system have an GPS pulse-per-second (PPS) input, which sends a pulse on each UTC second, good to 10s of nanoseconds.3. Some firmware on your FPGAs which allows an arm signal to be generated by software, causing some internal counter to be generated from the next PPS pulse edge. You then do the following: On your control computer you sleep until a second boundary passes. Then you issue an arm of the FPGA boards. You don't know exactly when this arm arrives -- NTP isn't that accurate, and the latency of issuing an FPGA write is unknown -- this is why you can't use this signal alone for defining timing. But... you *do* know the next second boundary that will follow the arm. On this second, a PPS (which is good to <100us) triggers the reset of your FPGA's counter logic. You can then use this counter to indicate time in FPGA cycles since reset. Since you know the reset time, if you use this counter to stamp data packets you can figure out the time associated with the data in these packets. You can probably do something in python like:from time import *sleep(1 - (time() % 1)) # Sleep until the next second boundarysleep(0.1) # sleep until 100ms past this secondmy_fpga.arm() # Arm the sync generator logicarm_time = int(time()) + 1 # The next second tick will pass at this time and reset your boards# write the arm_time somewhere, so that when you get a packet timestamped with some counter, you can do# time_of_this_packet = arm_time + (counter_value / counter_ticks_per_second) Maybe that was helpful. Maybe it will add to your confusion. Probably the above pseudo code doesn't work in real life :) CheersJack On Fri, 8 Mar 2019 at 10:50, Franco <francocuro...@gmail.com> wrote: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 that record the start time? Sorry if it is basic question. Thanks, Franco On Thu, Mar 7, 2019 at 3:52 AM James Smith <jsm...@ska.ac.za> wrote:Hello Franco, As I understand it, PTP wasn't terribly useful in our application (though I wasn't involved with this directly). You can probably sync the little Linux instance that runs on the ROACH2, but getting the time information onto your FPGA may prove somewhat tricky. Are you using an ADC card in the ROACH2? Or is the data digitised separately? What we've done with ROACH and ROACH2 designs in the past is more or less this: * FPGA's clock comes from a timing & frequency reference (TFR). * ROACH2 gets a 1PPS input from the same TFR. * In the FPGA logic there's a counter which is reset as part of the initialisation, and some logic that starts the counter going after a set number of 1PPS pulses (two to three, I forget exactly now). * The output of this counter is pipelined along with the data and then sent out as part of the SPEAD data on the 10GbE network.The idea here being that you know with a fairly high degree of precision which pulse your ROACH was initialised on. The counter that comes through on the SPEAD packet counts in FPGA clock cycles (or multiples thereof, perhaps you might want to count in spectra), and then you can use the start time to calculate the timestamp of each packet (Unix time, MJD, whichever your preferred reference is). Hope that helps. Regards,James On Wed, Mar 6, 2019 at 7:41 PM Franco <francocuro...@gmail.com> wrote:Dear Casperiites, I was given the task of timestamping ROACH2 spectral data in a telescope that uses PTP (precision time protocol) as a synchronization protocol. I understand that ROACH's BORPH come preloaded with NTP (network time protocol) libraries/daemos, but PTP is preferred because is already in use in the telescope, and it achieves greater time precision. Does somebody know if it is feasible to compile/install PTP libraries in BORPH? Alternatively, we have though of sending the ROACH the current time through a GPIO pin using IRIG-B timecode standard. Has anybody done something similar in the past? Thanks, Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
