@timjarsky
I'm looking into that.

The reason for the bunches are that we set the timestamps before iterating over all TPs for TP during DAQ, see

Now setting it in the loop will not make things much better as that will not differ much from the current value. The code is pretty fast already. And we should actually not use the time of pushing the TP data to evaluation but the time of acquisition. But getting the DAQ starting time of a single TP chunk is not something we already have.

Let's chat about that tomorrow.

TP during DAQ start times are grouped because the analysis time is used, not the acquisition time. Switch to using acquisition time. Calculate acquisition time from the high-precision start point of each sweep.

Reminder for Tim - calculating the chunk acquisition time is simple math. It's already written for TP storage, so this will have a minor impact on speed.

Idea how to get times precisely:

• Save time whenever a DAQ starts in a global from GetISO8601TimeStamp
• adapt ED_MarkSweepStart to use this time
• calculate TP time with DAQ start time + TP_Nr * TP_time_length
• TP_Nr is the TP in the current acquisition wave (NI loops use TP Nr directly, for ITC/Sutter use mod(tp_count, tp_block-size)
• verify that DAQ start time updates after a tp block for ITC/Sutter

• For ITC determine starttime in TFH_FifoLoop on acq start and return always fifopos and time together on readout update in mainthread global, tgId is per device
• drop tpInput.readTimestamp aka "now" (in thread) aka %NOW (in TPResults / TPStorage)
• calc tpInput.timestamp based on UTC time with date2secs(-1,-1,-1) adjust
• TP_FitResistance use non UTC timestamp for x values in fit