Continous data, where do the gaps come from...?

Let’s start with a few statements about how our system operates:

1. Our FOB card is the sample period controller.  
2. Each base sample period (ideally 1 millisecond, but this can be ever so slightly off) an IRQ is generated on the CPU(s) that is then handled by our kernel-mode driver.  See Appendix A
3. The ISR (interrupt service routine) that handles the FOB IRQ is responsible to buffer data in RAM (non-paged, dedicated memory) until the server can unload the buffer to store data to disk.
4. Data is buffered in the driver to ensure no loss of data.
5. ibaPDA server unloads this data and stores the data to disk knowing to which frames (sample period) it belongs.
   Frames are relative to a starting timestamp.
6. ibaPDA server can selectively use different methods to determine file’s starting timestamp.
   Use of the so-called high-performance counter to calculate the file “starttime” rather than taking it from the system clock causes the server to obtain the CPU clock frequency and the CPU performance counter.
   Generally speaking this start time is more accurate than querying the system time, which is accurate to about 10msec.
   However, there can also be inaccuracy in the CPUs clock frequency reported from the CPU.
7. When a data store is configured to store X number of seconds of data, a computation is made to determine the number of frames that must be stored.
8. The server then collects this number of frames from the driver buffer during the defined time period and stores them in a file with a “starttime” as computed using either the system time or a re-calculated time based on the high-performance counter.  
   As it does so, the driver continues to buffer data for the next file as the sequence repeats.

In other words the number of frames stored in a DAT file will always cover the required amount of data, however the start and stop times stored in the .DAT-files can not always be exactly matched. 

When you want to see the recorded data back in ibaAnalyzer there are 2 main methods to open .DAT-files:

1. Single .DAT-file

Nothing wrong here.
The start of the .DAT-file will be the “starttime” as stored in the info field of the .DAT-file.

2. Multiple appended .DAT-files

By default every .DAT-file will be placed on the timeline with the stored “starttime” from the infofield of the .DAT-file.

However if the stoptime of the previous file does not exactly match the “starttime” of the next one we can have a gap in the visualisation. Be assured this is only in the visualisation. In reality no data is missing or double, it is only the result of the way of visualisation.

This behaviour of visualisation can be avoided not do re-syncronisation between the Absolute time and the “starttime” of the .DAT-file for each appended file. 

 > Right click on the time-graph and uncheck 'Synchonize files on recording time'

           
Or in the general ibaAnalyzer 'Preferences':

By disabling the above option, you will synchronize the 'Absolute time' based on the infofield of the first .DAT-file, and append all the samples from the other .DAT-files after eachother. All other 'starttime' from the other files will be ignored.
This will result in a visualisation without any gaps in between.

---

Appendix A

The ibaFOB board has on-board a very stable interrupt source. In the example below the 'Aquisition timebase' is set to 10ms.
When using such a high stability clock we can assure that the time between 2 samples has sub-millisecond accuracy. In the example below (-202.2us | +176us)

.DAT-file time length is determinded in 2 ways, the sample count and the actuals Windows Time.

A .DAT-file of 30 minutes