<?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>2024-08-24T00:14:51Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-06-19T22:22:35Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Able to reproduce original issue with Dp version 4.0.1123  .

Tested  In dp Versions 4.0.1164.50884 ,4.2.440.50920 4.3.206.50891 and  and verified  test setup with bridge channel and Iepe channel correctly functions in diagnostics and realtime shows no offset when set to EU  and ADC  , both with 0 offset applied and  with different offsets applied  and offset can be removed  .

Offset is removed when offset removed is enabled on the particular sensor.

Tested as follows..

Setup:

1 Analog Channel  with Sig gen attached.
2 Iepe Channels with no input

test setups with both analog channels and Iepe channels , and setups with only analog channels.


Tested scenarios with both 0mv injected at diagnostics into bridge channel and some offset injected ( &lt;=100mv)
Confirmed offset  can be removed if there is offset and there is no additional offset shown in EU in realtime.


Tested as follows:
- Created a bridge sensor in sensor db 2400 mv range  no software filter, remove offset checked  sw zero method Diagnostic Level , sensitivity set to 1mv per Eu non porp, Shunt check disabled.

-created  two Iepe sensors in sensor db  range 10,000  sensitivity set to 1mv per Eu porp. Remove offset checked , no sw filter, sw zero method =diagnostic Level , Ac coupling enabled.

Created Test Setup and add 3 channels with the above sensors ( bridge and Iepe )  Using S6A connected sig gen to one Bridge channel , left one Iepe Channel floating and connected the other to 2.5k ohms using a decade box .

A. Ran test up to diagnostics  injected 0v from sig gen to the Bridge channel , verified diagnostics showed no offset .
Ran realtime and verified realtime EU showed no offset on bridge channel in EU , mv and ADC

B. Ran Test again injecting  an offset voltage form sig gen on the bridge channel  ( less than 100mv) from sig gen to bridge channel and verified diagnostics shows initial offset that matches the offset injected .



C. Repeated tests with different settings for Iepe sensor channels..

D. Repeated tests with only bridge channel(s) in the test.

E. Repeated tests in all 3 patched versions of datapro ..





</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2024-06-19T22:16:59Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-06-19T20:20:59Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-06-19T19:02:19Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Able to reproduce original issue with Dp version 4.0.1123  .

Tested  In dp Versions 4.0.1164.50884 ,4.2.440.50920 4.3.206.50891 and  and verified   test setup with bridge channel and Iepe channel correctly functions in diagnostics and realtime shows no offset when set to EU   and ADC   , both with 0 offset applied and  with different offsets applied  and offset can be removed  .

Offset is removed when offset removed is enabled on the particular sensor.

Tested as follows..

Setup:

1 Analog Channel  with Sig gen attached.
2 Iepe Channels with no input 

test setups with both analog channels and Iepe channels , and setups with only analog channels.


Tested scenarios with both 0mv injected at diagnostics into bridge channel and some offset injected ( &lt;=100mv) 
Confirmed offset  can be removed if there is offset and there is no additional offset shown in EU in realtime.


Tested as follows:
- Created a bridge sensor in sensor db 2400 mv range  no software filter, remove offset checked  sw zero method Diagnostic Level , sensitivity set to 1mv per Eu non porp, Shunt check disabled.

-created  two Iepe sensors in sensor db  range 10,000  sensitivity set to 1mv per Eu porp. Remove offset checked , no sw filter, sw zero method =diagnostic Level , Ac coupling enabled.

Created Test Setup and add 3 channels with the above sensors ( bridge and Iepe )  Using S6A connected sig gen to one Bridge channel , left one Iepe Channel floating and connected the other to 2.5k ohms using a decade box .

A. Ran test up to diagnostics  injected 0v from sig gen to the Bridge channel , verified diagnostics showed no offset .
Ran realtime and verified realtime EU showed no offset on bridge channel in EU , mv and ADC 

B. Ran Test again injecting  an offset voltage form sig gen on the bridge channel  ( less than 100mv) from sig gen to bridge channel and verified diagnostics shows initial offset that matches the offset injected .



C. Repeated tests with different settings for Iepe sensor channels..

D. Repeated tests with only bridge channel(s) in the test.

E. Repeated tests in all 3 patched versions of datapro ..

 




Need to test next With SPS ..

</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-06-19T18:57:28Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-06-19T16:58:13Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-06-19T15:11:30Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2024-06-11T22:53:19Z</TimeStamp>
    <ReleaseNote>Corrects an issue with S6A offsets on analog channels when an IEPE channel is present</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-06-07T17:54:26Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.2/4.3@39124
 
now when an IEPE is present it will wait IEPE WARMUP Time MS (in system settings) at the start of excitation warmup.  In addition, after IEPE coupling is reset and before final offset removals are made an additional IEPE warmup time MS is waited.
 
the second warmup does post status messages but does not have it's own progress bar with a cancel.
 
This was reported on a S6A, but probably should be tested with SPS as well.  In addition, not only the original test case needs to be tested but that regular analog offset removal still works as well after the change.</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2024-06-07T17:54:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>Here's my observations after a run.
 
with IEPE present here's the analog channel with offset removed.
 
 
AVE 119, std dev 47
 
and here's with with IEPE absent
 
 
ave ADC 121 with STD DEV of 48
 
I swear I got different results the first time I ran though, which looked like this:
 
 
 
 
I'm hoping I better controlled things in the second run and maybe I had some variable in the first run.  Here's the second run</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-06-07T17:46:19Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-06-07T16:20:30Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-07T18:07:00Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>on hold till support confirms they want to wait 1 + minute per diagnostics when there's an IEPE in the test.</Comment>
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-05-06T20:45:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-05-06T17:21:04Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>Jerry, John, but really Loc and Chris – and I’ll add SQA on here too just for some more background and eyes.
 
 
 
I’ve submitted a patch into 4.03 DEVEL for
 
 
 
39124 
 
S6A 2ch Bridge offset is different than 2ch Bridge and 2ch IEPE for Bridge channels.
 
 
 
This is a bit of a complicated issue.
 
 
 
Ohad (motiontech) noticed that when he had an IEPE sensor in a test DataPRO his bridge sensor was not properly zeroed, however whenever there was no IEPE sensor it was properly zero’d.
 
 
 
In my testing I used I had a floating/no sensor attached full range full bridge setup on channel 1, a full range stamp load cell connected on channel 2, and a not attached IEPE ac coupling sensor on channel 3.  The full bridge sensors were set to REMOVE offset during diagnostics and the IEPE sensor was set to NOT remove offset during diagnostics.  All three were set to zero EU using pre-test diagnostics as this seemed to be what was used by Ohad.
 
 
 
We have separate calls to remove offset and to measure the current offset.  In diagnostics we first remove the offset, then we make a final measurement for what the offset is and then we remember what the final offset is after removing offset.  If pre-test diagnostics is set as the zero method, then when calculating EU DataPRO will subtract the final offset in ADC from the measured offset so basically EU = (ADC – final offset DC) * scale factor.
 
 
 
Here’s what the call to remove offset looks like in the logs;
 
 
 
2024-05-03 15:13:43.128 -&gt;  Diagnostics - SetChannelOffset [00001253], S6A1036, local: 192.168.110.169:53401, Remote: 192.168.110.38:8301 StackChannels: (0, 1), ZeroTargets: (0, 0), TargetTolerances: (50, 50)
  
 2024-05-03 15:13:44.150 &lt;-  Diagnostics - SetChannelOffset [00001253]\[00001253] - (1020.7141ms), S6A1036 FinalZero: (16, 7), ZeroError: (16, 7)
 
 
 
And here’s what the final measurement looks like
 
 
 
2024-04-03 16:23:45.433 &lt;-  Realtime - RetrieveSampleAverage [00002907]\[00002907] - (70.9772ms), S6A0304 Channels: 6, Samples Used: 33, Data: (21, 22, 18, 21, 721, 768)
 
 
 
My first attempt at resolving the issue was to put a delay between the offset removal and the final offset measurement;
 
 
 
That’s these two calls here:
 
 
 
                        // remove offset
 
                        RemoveOffset(ChannelDiagnostics, info, ref results);
 
And
 
                        // measure final offset
 
                        MeasureFinalOffset(ChannelDiagnostics, info, ref results);
 
 
 
This worked when looking at the EU output, by inserting just a few seconds of delay before measuring the offset the final offset read in would closely match what was recording when collecting data.  HOWEVER, I then noticed that offset removal was not working properly in this case either;
 
 
 
I had a stapler on my load cell during diagnostics … this offset _should_ have been removed, but when I looked at the data here’s what I saw;
 
 
 
 
Versus when the IEPE was not in the test or set to DC, here’s what I saw;
 
 
 
 
Offset removal is not working properly anymore even if I added the delay. 
 
 
 
In this issue here: 16524: diagnostic result should include the resting voltage of an IEPE sensor - Manuscript (dts.local)
 
 
 
In this issue Mike Beckage requested that diagnostics should include the resting voltage of a sensor in IEPE using DC coupling.  This added code that switched all channels to DC, then switched the AC channels back at the end of diagnostics.
 
 
 
For the patch I abstracted out these two chunk of codes into their own functions for readability, and then moved the switch the restore code to before offset removal.   With this the offset removal works as expected for the stamp load cell, it’s close to 0 like in the second image above.
 
 
 
I think this is still OK with the request from 16524 as offset is still checked while in DC.
 
 
 
There’s a 5 second delay in the restoring back to the original offset coupling method.  This would not be sufficient for a sensor with AC coupling, but we should also not be doing offset removal with AC coupling.  We don’t currently restrict offset removal in this case.  5 seconds is longer than the 3 second delay when we have no IEPE sensors, but the amount of delay is a bit dependent on your sensor.  Some full bridge sensors can still take a long time to stabilize, potentially up to 40s for some sensors with a gain of 1.  Note this process of turning on DC then back to AC also removes the ability to just sit in diagnostics for a long time to allow for saturation, then doing a final offset removal or measurement once the channels are saturated as the coupling is always going to be switched if there’s an AC sensor present.
 
 
 
In testing I recommend having an analog sensor with a good amount of offset you want to remove, I used a stamp load cell with a heavy weight on it, but you can use a bridge plug with a sig gen just as well.  I would set up sensors with analog will remove offset and diag zero and an IEPE sensor with AC coupling and no remove offset.  I would add offset to the analog channels and then run diagnostics and collect data with the offset present.  Both ADC and EU will probably not be near zero before the patch, but after the patch both should be near zero.
 
 
 
Finally, this is a bit of a work around in software, there might be something firmware could do for this situation – it’s not clear why switching a channel to DC would cause offset removal to behave differently.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-06T17:20:53Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-05-03T23:30:47Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T22:34:19Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T22:30:59Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>well there may be some randomness involved, in a subsequent test with an AC IEPE the offsets read _ARE_ near 0ADC;
 
 
however you still need a delay before reading the measured offset if you are using pre-test zero, and we are not removing offset, which you probably also don't want to do for the IEPE sensor.
 
running again, I do see an offset after offset removal...</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T22:30:26Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T22:15:08Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>note however, the remove offset function here is not working as expected ... it's just the final offset is more accurate so you don't notice, the ADC readings are still further away from 0 than they should be ... I don't know that I have a solution for that.
 
 
AND in this case we were NOT removing offset for the IEPE channel in question;
 
2024-05-03 15:13:43.128 -&gt;  Diagnostics - SetChannelOffset [00001253], S6A1036, local: 192.168.110.169:53401, Remote: 192.168.110.38:8301 StackChannels: (0, 1), ZeroTargets: (0, 0), TargetTolerances: (50, 50)
  
 2024-05-03 15:13:44.150 &lt;-  Diagnostics - SetChannelOffset [00001253]\[00001253] - (1020.7141ms), S6A1036 FinalZero: (16, 7), ZeroError: (16, 7)
 
channels 0 and 1 are not IEPE channel, channel index 2 is the IEPE channel.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T22:10:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>testing this out with a shotgun 30s delay between the two calls I end up with properly zero'd data:
 
 
suggesting that a delay will work in getting the right output, however a 30s delay here is interminable, and it's non IEPE channels that the complaint against, will need to talk to Loc and Chris about this, in the mean time I'll see if there's an issue when you _don't_ remove offset from an AC IEPE sensor, which seems to be the what should be done in the first place.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T21:59:49Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T21:45:21Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T21:33:08Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>running my own test, here's what the final offsets look like when there's an IEPE sensor with DC.
 
2024-05-03 14:19:44.781 -&gt;  Attribute - SetArmAttribute [00000330], S6A1036, local: 192.168.110.169:51805, Remote: 192.168.110.38:8301 Key: StackChannelMeasuredOffsetADC, DataType: Int16Star, Length: 12, Overwrite: True, Value: (19, 7, 22, 684, 661, 670)
 
here's what the final offset looks like when there _is_ an AC sensor
 
2024-05-03 14:24:43.584 -&gt;  Attribute - SetArmAttribute [00000598], S6A1036, local: 192.168.110.169:51999, Remote: 192.168.110.38:8301 Key: StackChannelMeasuredOffsetADC, DataType: Int16Star, Length: 12, Overwrite: True, Value: (16, 8, 21, 686, 660, 669)
 
they look pretty identical, downloading I see this:
 
 
with ADC around -10 ADC
 
 
Pretest diagnostic level is 8
 
 
 
 
with out the AC IEPE ADC is around 0
 
 
and EU is also closer to 0
 
 
in FWTU the PreTestDiagnosticLevelADC is 13
 
 
 
 
this "FinalOffsetADC" is coming from these calls;
 

 2024-05-03 14:43:50.863 -&gt;  Attribute - SetArmAttribute [00000257], S6A1036, local: 192.168.110.169:52490, Remote: 192.168.110.38:8301 Key: StackChannelMeasuredOffsetADC, DataType: Int16Star, Length: 12, Overwrite: True, Value: (16, 8, 24, 686, 661, 669)
 
so in this case it would be 8, or the same value we get when we have an IEPE sensor present</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T21:25:48Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T21:13:25Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>To me it looks like the error is in what comes back from "RetrieveSampleAverage"
 
2024-04-03 16:23:45.433 &lt;-  Realtime - RetrieveSampleAverage [00002907]\[00002907] - (70.9772ms), S6A0304 Channels: 6, Samples Used: 33, Data: (21, 22, 18, 21, 721, 768)
 
vs
 
 2024-04-03 16:27:28.075 &lt;-  Realtime - RetrieveSampleAverage [00003139]\[00003139] - (69.7941ms), S6A0304 Channels: 6, Samples Used: 33, Data: (19, 20, 14, 18, 27502, 25785)
 
speaking to loc, whenever we call      Line  58: 2024-04-03 16:23:44.243 -&gt;  Diagnostics - SetChannelOffset [00002905], S6A0304, local: 192.168.4.10:54607, Remote: 192.168.4.4:8301 StackChannels: (0, 1, 2, 3), ZeroTargets: (0, 0, 0, 0), TargetTolerances: (50, 50, 50, 50)
 
it will switch it to DC, then back to AC, so you'd need a delay after this and then BEFORE the retrieve sample average to allow for the AC reading to be stable.
 
also from Loc ... Don't do that:
 
In general, we need to remind user if they are using AC coupler, they should (must) uncheck the "remove offset" from sensor setting.
 
There's normally more harm than goods trying to remove offset from AC coupling channel.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-03T21:10:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-24T15:50:36Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-23T18:11:22Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>i believe this was functional after case 16524. the sensor warmup was intended to be included when switching between AC to DC and DC back to AC to read offsets. It didn't appear that DataPRO was doing this when i was testing with Randy.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-16T17:32:53Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>It's not clear what the issue is here, it will take significant time to debug.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-16T17:24:34Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-04-16T17:18:52Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>Ohad Mitrani
 
 
 
 
 
 
 
 
 
Tuesday 14:00
 
 
 
 
 
 
To:
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
Hi
 
Any updates?
 
 
 
 
 
 
 
 
 
  
 
 
 
 
Chris Balogh 
 
 
 
 
 
 
 
 
 
 
 
 
 
less than a minute ago
 
 
 
 
 
 
To:
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
Hi Ohad,
  
 We're moving this through the queue. I'll give you an end date when I have more details from the team.
  
 Ill hold this ticket open for the time being.
  
 Talk to you soon,
 Chris</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-11T17:39:04Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>This looks to have been overlooked when reopened to be moved into the DataPRO project.</Comment>
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-04-11T17:36:33Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Randy Chu</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-04T18:01:57Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Randy Chu</User>
    <Comment>Reproducible on STM and NXP hardware
STM: G2D8
NXP: G0P0, G0Q5
preproduce on DataPro : 4.0.1123 , 4.2.353, 4.3.82

Issue was reported by the customer on firmware G0P0, DataPro 4.0.1123


The issue is 
A6air analog channel offset is incorrect if there is a channel uses IEPE sensor with AC coupler. 
If a test setup has IEPE sensor and bridge sensor. All the sensor has remove offset checked.
The bridge sensor offset was not removed if one of IEPE sensor has AC coupler.
The bridge sensor offset was removed if all of IEPE sensor has DC coupler.

Step:
1. import test setup
2. Apply 100mV DC to bridge sensor
2. run the test till real time.
Expect:
The EU graph should show all channel close to zero.
See graph channel 3, 4

Happend:
the bridge sensor has off set that was not removed.
See graph channel 3, 4


below is comparing DataPro log during diagnostic run.
The different between two run is IEPE sensor has DC or AC coupling
I don't see difference in DataPro behavior. But DAS show the offset difference in real time. 

============ DC couple
    Line  50: 2024-04-03 16:23:43.694 -&gt;  Diagnostics - QueryChannelOffset [00002903], S6A0304, local: 192.168.4.10:54607, Remote: 192.168.4.4:8301 StackChannels: (0, 1, 2, 3)
    Line  52: 2024-04-03 16:23:43.871 &lt;-  Diagnostics - QueryChannelOffset [00002903]\[00002903] - (177.0408ms), S6A0304 Measured Offset (mv): (7686.522, 7532.336, 100.0341, 100.0698)
    Line  58: 2024-04-03 16:23:44.243 -&gt;  Diagnostics - SetChannelOffset [00002905], S6A0304, local: 192.168.4.10:54607, Remote: 192.168.4.4:8301 StackChannels: (0, 1, 2, 3), ZeroTargets: (0, 0, 0, 0), TargetTolerances: (50, 50, 50, 50)
    Line  60: 2024-04-03 16:23:45.361 &lt;-  Diagnostics - SetChannelOffset [00002905]\[00002905] - (1117.6834ms), S6A0304 FinalZero: (21, 22, 17, 21), ZeroError: (21, 22, 17, 21)
2024-04-03 16:23:45.362 -&gt;  Realtime - RetrieveSampleAverage [00002907], S6A0304, local: 192.168.4.10:54607, Remote: 192.168.4.4:8301 Samples Requested: 33
2024-04-03 16:23:45.433 &lt;-  Realtime - RetrieveSampleAverage [00002907]\[00002907] - (70.9772ms), S6A0304 Channels: 6, Samples Used: 33, Data: (21, 22, 18, 21, 721, 768)
    Line  70: 2024-04-03 16:23:45.433 -&gt;  Attribute - SetArmAttribute [00002908], S6A0304, local: 192.168.4.10:54607, Remote: 192.168.4.4:8301 Key: StackChannelMeasuredOffsetADC, DataType: Int16Star,


============AC couple
    Line  58: 2024-04-03 16:27:26.342 -&gt;  Diagnostics - QueryChannelOffset [00003135], S6A0304, local: 192.168.4.10:63270, Remote: 192.168.4.4:8301 StackChannels: (0, 1, 2, 3)
    Line  60: 2024-04-03 16:27:26.517 &lt;-  Diagnostics - QueryChannelOffset [00003135]\[00003135] - (175.0883ms), S6A0304 Measured Offset (mv): (7686.522, 7532.336, 100.0227, 100.0622)
    Line  66: 2024-04-03 16:27:26.891 -&gt;  Diagnostics - SetChannelOffset [00003137], S6A0304, local: 192.168.4.10:63270, Remote: 192.168.4.4:8301 StackChannels: (0, 1, 2, 3), ZeroTargets: (0, 0, 0, 0), TargetTolerances: (50, 50, 50, 50)
    Line  68: 2024-04-03 16:27:28.004 &lt;-  Diagnostics - SetChannelOffset [00003137]\[00003137] - (1113.38ms), S6A0304 FinalZero: (19, 20, 15, 18), ZeroError: (19, 20, 15, 18)
 2024-04-03 16:27:28.005 -&gt;  Realtime - RetrieveSampleAverage [00003139], S6A0304, local: 192.168.4.10:63270, Remote: 192.168.4.4:8301 Samples Requested: 33
 2024-04-03 16:27:28.075 &lt;-  Realtime - RetrieveSampleAverage [00003139]\[00003139] - (69.7941ms), S6A0304 Channels: 6, Samples Used: 33, Data: (19, 20, 14, 18, 27502, 25785)
    Line  78: 2024-04-03 16:27:28.076 -&gt;  Attribute - SetArmAttribute [00003140], S6A0304, local: 192.168.4.10:63270, Remote: 192.168.4.4:8301 Key: StackChannelMeasuredOffsetADC, DataType: Int16Star, Length: 12, Overwrite: True, Value: (19, 20, 14, 18, 27502, 25785)


</Comment>
    <StatusString>Reactivated</StatusString>
    <TimeStamp>2024-04-04T18:00:16Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Reactivated</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>\\dts.local\files\HelpCenter\Private\Zendesk\13319</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-02T15:43:25Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-02T15:42:55Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-04-02T15:42:39Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>need SQA to test</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2024-03-31T23:33:35Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-03-31T23:33:02Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>https://dtsweb.zendesk.com/agent/tickets/13319
 
 
 
Ohad is reporting that his customer sees different offsets in data if IEPE channels are included.
 
This could be FW/HW/SW. Unknown without reproducing or logs.
 
 
 
 
 
 
  
 
 
 
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 05:08
 
 
 
 
 
 
To:
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Hi
 
We found a bug in DP 4.0.1123 that is related to not getting diagnostic zero.
 
any newer DP version? 
 
 
 
 
 
 
 
 
 
  
 
 
 
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 07:44
 
 
 
 
 
 
To:
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
So this is the situation:
 
- a test with 2 IEPE and 2 Bridge sensors
 
- target is to use diagnostic zero - meaning that the test will start with zero value on the sensors. 
 
if the setup is ONLY with the 2 bridge sensors - all works great. But after adding the 2 IEPE sensors, the bridge sensors are simply not zeroing. This is done on my Slice6 Air system - so I have access to everything. need to solve this asap. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Zero_Bug
 
XML
 
 
 
 
 
 
 
 
 
 
  
 
 
 
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 07:45
 
 
 
 
 
 
To:
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DP 4.0.1123
 
FW G0P0
 
 
 
 
 
 
 
 
 
  
 
 
 
Chris Balogh 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 09:02
 
 
 
 
 
 
 
 
 
Hello Ohad,
 
 Thank you for the detailed report. I'll get this in front of the engineering team.
 
 Do you have a collected data set for this, just in case there's an issue reproducing on our side?
 
 Talk to you soon,
 Chris
 
 
 
 
 
 
 
 
  
 
 
 
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 09:04
 
 
 
 
 
 
To:
 
DTS
 
 
 
 
 
 
 
 
 
 
 
 
 
I’ve attached the test setup.  
Im available whenever needed to show in realtime the issue  
 
 
Ohad Mitrani
 
 
 
 
  
On 31 Mar 2024, at 19:02, Chris Balogh (DTS) &lt;support@dtsweb.zendesk.com&gt; wrote:
  
 
 
 
 
 
 
 
 
 
 
 
 
  
 
 
 
Chris Balogh 
Internal
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 09:06
 
 
 
 
 
 
 
 
 
I'm not convinced this is a DataPRO issue.
 
 
 
 
 
 
 
 
  
 
 
 
Chris Balogh 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 09:10
 
 
 
 
 
 
 
 
 
Hi Ohad,
 
 I'm mostly interested in the logs between the two runs (bridge only; bridge+iepe). The logs will show the offset values. If the logs differ, the delta is coming from the hw or fw. If not, then SW is doing something wrong. Trying to narrow it down before I hand it off. It's not something have equipment to test at the moment. It's the first thing I'd have our qa team do Monday morning.
 
 Talk to you soon,
 Chris
 
 
 
 
 
 
 
 
  
 
 
 
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 09:23
 
 
 
 
 
 
To:
 
DTS
 
 
 
 
 
 
 
 
 
 
 
 
Tell me what files you need exactly, and I will generate them.
 
I found those 2 that shows you the setup with 2ch vs 4ch.
 
 
 
Btw – using average over time did work. I’ve also attached to initial ticket (and again now) the test setup. 
 
 
 
 
Ohad Mitrani | CTO
 
 
 
 
 
                 +972 58 6468008                    +972 9 9566466
 
    mitrani@motiontech.co.il          www.motiontech.co.il       ohadmitranimobile
 
 
 
 
 
 
 
           *    Type or Click the Waze Link: MotionTech Office             
 
 
 
 
 
 
 
 
 
 
 
 
 
~WRD0000
 
JPG
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DataChannels_638475030874380475
 
XML
 
 
 
 
 
 
 
 
 
 
 
 
 
DataChannels_638474991605213395
 
XML
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Zero_Bug
 
XML
 
 
 
 
 
 
 
 
 
 
  
 
 
 
Chris Balogh 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 09:33
 
 
 
 
 
 
 
 
 
Hi Ohad,
 
 The average overtime will work, yes, but there could be a real issue it's masking.
 
 What would help is to have the whole test id folders from the \data\[test setup]\[test id]\ for 2ch and 4ch. That will include everything I need.
 
 Just a heads up: I will be in and out for the next several hours. I have church and then we're hosting family for Easter.
 
 Talk to you soon,
 Chris
 
 
 
 
 
 
 
 
  
 
 
 
 
Ohad Mitrani
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Today 10:05
 
 
 
 
 
 
To:
 
DTS
 
 
 
 
 
 
 
 
 
 
I don’t have any recording with the 4ch on me sk will do this tomorrow.  
If we can set a webex session for tomorrow I can show you in real time the issue and we can log whatever is needed  
 
Ohad Mitrani
 
 
 
 
  
On 31 Mar 2024, at 19:33, Chris Balogh (DTS) &lt;support@dtsweb.zendesk.com&gt; wrote:</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2024-03-31T23:33:01Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>