<?xml version="1.0"?>
<ArrayOfFBEvent xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-07T14:17:55Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Jaime Lopez</User>
    <Comment>Verified with DataPRO v4.0.959, 4.1.315
 
Exported CSV file and verified zero method is set to none for all channels.
 
 
before patch</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2023-06-06T17:06:02Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Jaime Lopez</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-06-02T23:46:08Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T17:58:06Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.1@48804
 
now AbsoluteZero/None is forced for all TSR AIR sensors, which addresses both issues, I'll open up a new issue of lower priority to look at average over time in general when there's a 0-x second
 
[update, don't have to since this is TSR AIR specific and related to whether the diagnostic information is available or not].</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-06-01T17:56:29Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>finally able to duplicate using 0-5s active mode with filtered export.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T17:02:36Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>and then errors downloading
 
2023-06-01 08:45:57.671 QueryEventData.WholePackagePost: reporting failure, status==(unknown) (0x61)</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T16:04:49Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>TA0061 lost it's brains when I armed with 0s pre (couldn't read FRAM), rebooted, no serial, reset ip and serial.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T15:57:52Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T15:42:22Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T15:41:33Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>provided screencap starts at 0s, and has 0 pretrigger ... maybe they are using a different recording mode?
 
also possible - maybe they are doing an roi download from 0-x?
 
or maybe they used copy and trim to go from 0-x
 
or maybe this was downloaded from two separate versions?</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T15:37:44Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>could not duplicate even after changing pretrigger to .04 ...</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T15:36:28Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>am still not able to duplicate.
 
I do notice that both my CSV have DataZeroLevel specified ... In my case the data zero window is contained, I'll shorten my pretrigger so that it's not.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T15:08:58Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>first attempt at duplicating, no joy.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T14:57:40Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>in the view tab they look perfectly aligned...</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-01T14:54:06Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>re-opened per CPB for taking a look at a potential difference between a download in run test and a download in the download tab.</Comment>
    <StatusString>Reopened</StatusString>
    <TimeStamp>2023-05-31T19:55:14Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-24T20:57:22Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-04-11T20:24:34Z</TimeStamp>
    <ReleaseNote>Corrects an issue where average over time software zeroing would use points outside of roi for averaging rather than using PreTestZeroLevelADC when not all of ROI is available.</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Closed</StatusString>
    <TimeStamp>2023-04-11T20:23:42Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-04-11T20:23:39Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Reopened</StatusString>
    <TimeStamp>2023-04-11T20:23:36Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Jaime Lopez</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-04-04T18:05:04Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Jaime Lopez</User>
    <Comment>Verified w/ 4.0.907, 4.1.254
 
with accel 1 pointing to earth run diagnostics, Once armed and waiting for scheduled time stop monitoring. Once event is recording flipped and perform 2g roll.
 
Pre-patch offset was about ~ 23g Post-patch ~ -1g
 
Pre Patch:
 
 
Post Patch:
 
 
Downloading in FWTU:</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2023-04-04T18:03:26Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Jaime Lopez</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-04-03T15:06:12Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.1@48452</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-03-29T23:55:00Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-29T14:41:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>Chris, John, Farshid,
 
I've submitted a patch in 4.0 MAINT for:
 
30446
 Unexpected DataZeroLevelADC 15292 when scheduled recording with TSR AIR at 100sps
 
The link above has a dataset which demonstrates the issues.  With this issue on offset of around 23g is seen on channel 1 (note if viewing in EU you have to switch to unfiltered display)
 
 
 
 
I tracked this down to the zero method used for the channel.  The channel is set for average over time from -.05 to .05, however the channel does not contain any pre trigger data.
 
the problem lies in this operation here:
 
                                                for (var i = startingIndex; i &lt; startingIndex + numSamples; i++)
                                                 {
                                                     //don't try to access any indicies that are out of range
                                                     if (i &gt;= 0 &amp;&amp; (long)i &lt; pc.Length)
                                                     {
                                                         windowSamples[insertPoint++] = Convert.ToDouble(pc[i]);
                                                     }
                                                 }
 
we calculate the starting index for the window based on the ROI begin seconds, the pretrigger time available, and the sample rate.  It then just collects samples from the starting index to the number of samples it needs for the average.  It does check if the index is greater than 0 and (when cast to a long) is less than the length of the channel.  (the sample array index is in ulong).  This creates a situation where the starting index is always greater than equal to 0 (since it's a ulong) and potentially when cast to a long will also be less than the length of the channel.  This results in the unpatched code grabbing samples in an unexpected way from an ROI window that isn't really valid.  I'm guessing since there's a check for &gt;=0 against a ulong the variable may have originally been stored in a double.
 
To deal with this the patch adds two separate new checks in.
 
the first check is to protect against an underflow with the ulong;
 
                                                if (preTriggerTime == 0 &amp;&amp; ZeroAverageWindow.Begin &lt; 0)
                                                 {
 
if this is violated it will output in the log:
 
APILogger.Log($"{FileName} Average over time window is not available, using PreTestZeroLevelADC");
 
the second check may be unnecessary, but was put in for caution.  Anytime the starting index is greater than a max long this is another sign that case to long is going to underflow and shouldn't be allowed.
 
With the TSR AIR it would be more desirable to use the zeromethod "None" with scheduled recording modes as the state of offset at recording time and it's relation to the offset at diagnostics or any other time could be unknown.  This patch does not change that, however since we don't record the offset in diagnostics for the TSR AIR, returning the PreTestZeroLevelADC is consistent with the None zeroing method.
 
after the patch it will look like this:
 
 
I think this is property is eligible for n-unit tests, but not as it's currently implemented.
 
The zeroing function should be abstracted out into a function and the property can call the function and the input to the function can be changed to allow for this.  I'll add a separate issue to update this function in the future and potentially add the n-unit function, but it'll go into the undecided bucket for now.  I forgot to cover it in the sprint, but it is my intention that there should be some time in a sprint to be allowed on pet project items, so maybe this will end up in one for me at some point.
 
The logging just uses the file name and shouldn't throw an exception even if there's a null there, and I think the checks themselves are pretty safe, so I think it's sufficient to just test this issue with the dataset attached to the MS issue, however this issue could be present (and probably is) on versions before 4.0.  It would possible create an unexpected offset in EU when there's an average over time and the ROI window is not in the dataset.</Comment>
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-03-29T14:39:08Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>CPB favors this using the default behavior (using pretestdiagnosticadc) when ROI window doesn't contain.  He would prefer None, as the mounting may change between diagnostics is run and the unit is armed, or other issues may also change the offset.  In this case None is the same as pretestdiagnosticadc because we don't record the offset level during TSR AIR diagnostics ...</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-28T23:43:26Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-28T14:50:31Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-28T14:50:26Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-03-28T14:49:45Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-03-27T23:36:25Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-27T23:34:38Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>sensors are set for AVE over TIME from -.05 to -.02
 
there are 4 samples in that time range;
      Name Value Type     windowSamples[0] 16191 double     windowSamples[1] 16191 double     windowSamples[2] 16703 double     windowSamples[3] -1037 double    
 
 
this average is 12,012.  This means 12,012 ADC will be removed before calculating EU for any samples in this test.
 
Did you want a different zero method?  this can be changed ...
 
if you change it in the .dts file to "None" you'll end up with this.
 
 
 
 
what is the desired setting for this channel for zeroing?</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-27T23:30:21Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-27T21:33:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-27T20:32:17Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-03-27T20:31:51Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-03-27T20:29:50Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>https://dtsweb.zendesk.com/agent/tickets/11669
 
ticket pdf attached.
 
 
 
I'm able to reproduce in the customers build of 4.0.896. Customer set up for 120sec of scheduled recording. I did a series of 2g rolls every 10sec or so after recording started. I have Aimee's unit TA0170 at my bench.
  
 Data folder zipped and attached.
  
 
DP 4.0.896 View Data
 

  
 
FWTU Download of ADC direct from unit
 

  
  
 
FWTU View Data (to see ADC values)
 
Notice the same 15292 DataZeroLevelADC that the customer had on the CHN file and the same start from 0 ADC in the CHN.</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2023-03-27T20:29:49Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>