Hi David, Dan, Thanks for the explanation, my English failed me this time around (problems of a non-native speaker ¯\_(ツ)_/¯ )
Regards, Franco On Mon, Mar 11, 2019 at 1:19 PM Dan Werthimer <d...@ssl.berkeley.edu> wrote: > > 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. > -- 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.
