You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The specification uses the field TimeUnit to specify the unit that times are stored in. This field is used in many places including /nirs(i)/data(j)/time, /nirs(i)/probe/timeDelays, /nirs(i)/aux(j)/time etc.
However, the /nirs(i)/stim(j)/data field specifies that seconds must be used. It states (accentuation my own)...
This is a numeric 2-D array with at least 3 columns, specifying the stimulus time course for the jth condition. Each row corresponds to a specific stimulus trial. The first three columns indicate [starttime duration value].
The starttime, in seconds, is the time relative to the time origin when the stimulus takes on a value; the duration is the time in seconds that the stimulus value continues, and value is the stimulus amplitude. The number of rows is not constrained. (see examples in the appendix).
This seems counterintuitive to me. Ideally the same time unit would be used all throughout the specification. Unfortunately, changing this would be a breaking change. So I am tagging this as "breaking change" and "Version 2" so that we track this inconsistency and can possibly fix it in the future.
The text was updated successfully, but these errors were encountered:
rob-luke
added
breaking
A change that would break backwards compatibility with previous releases of the specification
v2.0
Things to be considered for version 2
labels
Apr 27, 2022
The specification uses the field
TimeUnit
to specify the unit that times are stored in. This field is used in many places including/nirs(i)/data(j)/time
,/nirs(i)/probe/timeDelays
,/nirs(i)/aux(j)/time
etc.However, the
/nirs(i)/stim(j)/data
field specifies that seconds must be used. It states (accentuation my own)...This seems counterintuitive to me. Ideally the same time unit would be used all throughout the specification. Unfortunately, changing this would be a breaking change. So I am tagging this as "breaking change" and "Version 2" so that we track this inconsistency and can possibly fix it in the future.
The text was updated successfully, but these errors were encountered: