hi franco,
i think we picked the word "arm" because it's similar to arming a gun, getting it ready to fire, but not firing it. "arm" is not the signal that directly resets the elapsed time counter. the arm signal is a software command that says: on the next 1 PPS, the elapsed time counter should be reset. "arm" is a fpga register bit that is set by a software command, perhaps at 23:59.59.5 (roughly 1/2 second before midnight). after the arm signal is set by the computer, then a very accurate external 1 PPS pulse, (perhaps from a gps disciplined time/frequency standard, accurate to a few ns wrt to UTC) resets the elapsed time counter. the elapsed time counter then is embedded in the ethernet packets with the spectral or voltage data, so that each packet is accurately time stamped to a few ns accuracy. best wishes, dan On Mon, Mar 11, 2019 at 7:37 AM Franco <francocuro...@gmail.com> wrote: > Hi, > > Yes! Very clear. Thank you very much James, Jack and Dan. Just the last > little question, why you call "ARM" the signal/register that resets the > time-tracking counter? > > Thanks, > > Franco > > > > On Mon, Mar 11, 2019 at 4:27 AM James Smith <jsm...@ska.ac.za> wrote: > >> 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 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 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 boundary >>> sleep(0.1) # sleep until 100ms past this second >>> my_fpga.arm() # Arm the sync generator logic >>> arm_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 :) >>> >>> Cheers >>> Jack >>> >>> 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. > -- 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.
