Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make epochs sample point exact #1990

Merged
merged 35 commits into from
Mar 22, 2024
Merged

Conversation

MichaelHuth
Copy link
Collaborator

@MichaelHuth MichaelHuth commented Jan 25, 2024

  • Check / Fix current WB segment / signal creation
  • WB: Add indice information to stimset wave note for all epoch-relevant segments / signal structures
  • Create a routine that converts such stimset index to an DAQDataWave index (after resample)
  • Gather all epoch-relevant signal structures from DC as indices (DAQDataWave based)
  • Create Epochs sample accurate
  • Split EP_AddEpochsFromStimSetNote into separate functions
  • Fix current epoch tests and epoch dependent tests (epochs are now hardware dependent)
  • Add more epoch tests
  • Make epoch creation API device independent
  • Make inflection epochs sample exact
  • Fix epoch end correction if acquisition was aborted to be sample exact on DA

close #1147
close #2003
close #2028

requires #2033 solved. Otherwise CI will most likely fail randomly when this issue comes up.

@MichaelHuth MichaelHuth self-assigned this Jan 25, 2024
@MichaelHuth MichaelHuth force-pushed the feature/1990-make_epochs_samplepoint_exact branch 6 times, most recently from 091ee98 to d4e9504 Compare February 1, 2024 20:34
@MichaelHuth MichaelHuth force-pushed the feature/1990-make_epochs_samplepoint_exact branch 8 times, most recently from 85312c0 to cbc250c Compare February 12, 2024 12:37
@MichaelHuth
Copy link
Collaborator Author

@t-b I thought about the effective stimset length increase for TTL on ITC and if it can happen on DA too.
I came to the conclusion that it can not happen because:
On TTL what happens is that if you have 2+ TTL channels where at least one has a shorter stimset than the others, all TTL channels are put in a 2D wave that has the size of max(TTLChannel_Stimsets). This happens in DC before the TTL channels are decimated into the data wave. Thus, considering the single TTL stimset in DC the length gets increased and then decimated with the increased length.

For DA on the other hand, the stimset from WB is never increased in size in DC and never decimated to the data wave with the increased size. So singleSetLength stays valid here for the decimated stimset size.
(The delta mechanism for another sweep extends the stimset within the WB and not "externally" later in e.g. DC)

@MichaelHuth MichaelHuth force-pushed the feature/1990-make_epochs_samplepoint_exact branch 10 times, most recently from d271be9 to 742832d Compare February 20, 2024 13:55
@MichaelHuth MichaelHuth assigned t-b and unassigned MichaelHuth Feb 20, 2024
- the first point in an inflection epoch is the point in the DA wave
  after the zero crossing. (if the epoch time is converted to points)
- finds first NaN row index in a floating point wave
- before the epochs should be sample exact the global EndTime of epochs was
  corrected after the acquisition to the time of the last acquired AD wave
  sample point. This happened even, when the acquisition was not stopped
  early. This had two consequences:
  - The global EndTime of epochs that by definition are based on DA timings
    got a value that was based on AD timing, that may not be sample exact to DA points.
  - The previously created Epochs were always cut by at least one point, even when
    the DA and AD samplerate was equal and the acquisition was not aborted.
	This also contradicts the new design where the end of an epoch is after the last
	valid point of the epoch.

- This commit changes the definition of plannedTime and acquiredTime that is used for
  determination of the applied global EndTime for epochs:
  plannedTime: Originally planned time based on the DA samplingInterval. It refers to
               the time of the point at the (effective) DA wave length + 1.
  acquiredTime: Actual acquired time based on the AD samplingInterval. It refers to
               the time of the last acquired point in the AD wave.

- The point acquiredTime refers to is usually fifoPosGlobal - 1 and must match that value.

- acquiredTime is only set if the acquisition was aborted early (otherwise NaN).
- If the acquisition was aborted early the index of the DA sample that is left of
  acquiredTime is calculated and plannedTime is then the time of (index + 1).
  This ensures that the plannedTime is sample exact regarding DA.
  (for TTL channels, the TTL sampling is used instead)
@MichaelHuth MichaelHuth force-pushed the feature/1990-make_epochs_samplepoint_exact branch from 1a72c94 to 8257182 Compare March 19, 2024 00:45
sets dimension labels based on 1d wave elements contents

- works with text and numerical waves
- allows to specify prefix and suffix
- has strict flag to check for dimlabel collisions/invalidities
- variable sampling interval
- variable sampling multiplier
- tests for ITC joined TTL wave decimation carry over to stimset end
- Epochs now start with an epoch point inside the epoch and end with a
  point outside the epoch. This was not taken into account by SF.

- Changed calculation to be mostly index based (integer)
- also add annotated graphs for epochs (pulse train and trigonometric)
@MichaelHuth MichaelHuth force-pushed the feature/1990-make_epochs_samplepoint_exact branch from 8257182 to cf8cec1 Compare March 19, 2024 00:47
@MichaelHuth
Copy link
Collaborator Author

rebased

@timjarsky
Copy link
Collaborator

@MichaelHuth @t-b, what is the definition of "sample point exact"? Is it a functional definition, or should the difference between the epoch time and the sample point = 0?

I ask because I do see a tiny difference between the epoch time and sample point;
image

@timjarsky
Copy link
Collaborator

@t-b
Copy link
Collaborator

t-b commented Mar 21, 2024

2e-6ms is a nanosecond, but I'll let Michael reply. (I'm still on the train travelling ...)

@MichaelHuth
Copy link
Collaborator Author

MichaelHuth commented Mar 21, 2024

I have to look into that, where that ns deviation could originate from.

What I can already tell is that the effect is from a conversion from double precision to single precision somewhere.

@MichaelHuth
Copy link
Collaborator Author

@timjarsky The issue was that the waves for the traces for displaying the epochs were in single precision. I pushed a commit that changes the trace waves to be double precision and this seems to fix the difference here. The small discrepancy should be gone now.

@t-b t-b self-requested a review March 22, 2024 16:12
@t-b t-b merged commit ad735dd into main Mar 22, 2024
19 checks passed
@t-b t-b deleted the feature/1990-make_epochs_samplepoint_exact branch March 22, 2024 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment