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.

Reply via email to