<html><body><div style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000"><div>The time stamps are added by the EPICS server hosted on the cRIO when the data is passed. A separate time stamp PV from the cRIO can be added to help with the stitching together of data arrays. Another solution could be to pass all data in one array (as done to the PLC) rather than as individual variables. However, this might take more work on the EPICS side to parse the data array.<br></div><div><br data-mce-bogus="1"></div><div>Best regards,<br></div><div>Tyler<br data-mce-bogus="1"></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><b>From: </b>"Nicholas Sandoval" <sandoval@jlab.org><br><b>To: </b>"Wesley Moore" <wmoore@jlab.org><br><b>Cc: </b>"Ruben Fair" <rfair@jlab.org>, "Tyler Lemon" <tlemon@jlab.org>, "Probir Ghoshal" <ghoshal@jlab.org>, "Nathan Baltzell" <baltzell@jlab.org><br><b>Sent: </b>Monday, January 30, 2017 10:27:04 AM<br><b>Subject: </b>Re: HallB torus/solenoid fastdaq time gaps<br></div><br><div data-marker="__QUOTED_TEXT__">This implies to me that the time stamps are then added after the FPGA and not the real time of the parallel ADC samples. If this is correct then a new field should be created which uses the real time the sample is made and sent along with the data. This time should be the one used for event reconstruction, and not the time stamp that gets added during the buffering. IE the time stamp of the serial filling process.<br><br> <br><br>----- Original Message -----<br>From: "Nathan Baltzell" <baltzell@jlab.org><br>To: "Wesley Moore" <wmoore@jlab.org><br>Cc: "Nicholas Sandoval" <sandoval@jlab.org>, "Ruben Fair" <rfair@jlab.org>, "Tyler Lemon" <tlemon@jlab.org>, "Probir Ghoshal" <ghoshal@jlab.org><br>Sent: Monday, January 30, 2017 9:55:56 AM<br>Subject: Re: HallB torus/solenoid fastdaq time gaps<br><br>There is also random jitter on the timestamps from one tap's reading to its next. If you histogram the difference between one tap’s Nth reading and (N+1)th reading, it has a spread of 30 ms if I remember correctly.<br><br><br><br>On Jan 30, 2017, at 9:45, Wesley Moore <wmoore@jlab.org> wrote:<br><br>> IIRC, the issue is how the epics buffers are filled on the cRIO. The sampling may be parallel as you say, but the epics PVs filled serially. <br>> <br>> Wesley<br>> <br>>> On Jan 30, 2017, at 8:05 AM, Nicholas Sandoval <sandoval@jlab.org> wrote:<br>>> <br>>> Hi Ruben and Tyler,<br>>> <br>>> Related to problem two that Nathan described below is individual time stamps for each VT. <br>>> <br>>> The cRIO was picked for this application because of the capability to sample all voltage taps in parallel. We should not have different time stamps for each set of samples. Every 1/2000 set of 24 VT samples should have a single time stamp that allows tordaqgui to align them. This is not the case when reviewing the raw data in Excel for example.<br>>> <br>>> The investigation should determine if in fact the cRIO is sampling each channel at different times or if this is just a time stamp that gets added after FPGA or some phenomena in the buffering.<br>>> <br>>> This seems to be the reason why Probir and I were unable to find the exact combination of voltage taps that stacked up resulting in the 3000A fast dump tripping the PLC comparator even though both streams of data should be the same.<br>>> <br>>> <br>>> Best Regards,<br>>> <br>>> Nick<br>>> <br>>> <br>>> <br>>> <br>>> ----- Original Message -----<br>>> From: "Nathan Baltzell" <baltzell@jlab.org><br>>> To: "Ruben Fair" <rfair@jlab.org><br>>> Cc: "Tyler Lemon" <tlemon@jlab.org>, "Nicholas Sandoval" <sandoval@jlab.org><br>>> Sent: Saturday, January 28, 2017 9:08:00 AM<br>>> Subject: Re: HallB torus/solenoid fastdaq time gaps<br>>> <br>>> Sure, sounds good.<br>>> -Nathan<br>>> <br>>> <br>>> On Jan 27, 2017, at 11:05 PM, Ruben Fair <rfair@jlab.org> wrote:<br>>> <br>>>> Thanks Nathan<br>>>> <br>>>> Tyler will be investigating this phenomenon further. Perhaps he can come and talk to you sometime next week?<br>>>> <br>>>> Regards<br>>>> <br>>>> Ruben<br>>>> <br>>>>> On Jan 27, 2017, at 10:18 PM, Nathan Baltzell <baltzell@jlab.org> wrote:<br>>>>> <br>>>>> Hi Ruben,<br>>>>> <br>>>>> I heard you are wanting to solve the time gap problem in fastdaq data and thought I'd comment on some things we discovered during torus commissioning.<br>>>>> <br>>>>> There are at least two known possible sources of time gaps in the software side of this cRio-EPICS system:<br>>>>> <br>>>>> One is discrete (currently 200 ms) gaps. Those are because the EPICS records are updating at a fixed frequency (currently 5 Hz, using 2K-long arrays to result in 10 kHz data acquisition), and there are instances where updates get missed between the cRio and the softIOC which result in fixed (200 ms) time gaps. The first time we saw that error was after increasing the data acquisition rate from 2 to 10 kHz (i.e. increasing the EPICS update rate from 1 Hz to 5 Hz). Even at 10 kHz, we still didn't see much of this problem after software was working correctly, but a fixed time gap size is indicative of this problem.<br>>>>> <br>>>>> Two is random jitter. That comes entirely from the timestamp reported by the cRio, and the application tordaqGui currently honors the timestamps from the cRio. Before the increase from 1 Hz to 5 Hz that jitter was at most few-ms. After the increase, it became 10s of ms.<br>>>>> <br>>>>> Another important point is that the EPICS Live Fast-DAQ screen contains zero information about time gaps. It's good for injecting signals and looking at noise levels, but completely useless for understanding time gaps.<br>>>>> <br>>>>> Regards,<br>>>>> Nathan<br>><br></div></div></body></html>