<?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>Closed</StatusString>
    <TimeStamp>2024-01-16T21:35:52Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Resolved</StatusString>
    <TimeStamp>2024-01-16T21:35:50Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Reopened</StatusString>
    <TimeStamp>2024-01-16T21:35:47Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2024-01-16T21:10:19Z</TimeStamp>
    <ReleaseNote>Now alerts the user in the UI when a SPT squib resistance fault occurs during arming</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Jaime Lopez</User>
    <Comment>Verified with DataPRO v4.2.324, 4.0.1119</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2024-01-11T01:02:56Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Jaime Lopez</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-01-08T17:12:20Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.2@50019
 
  
 
in the issue Nissan failed to arm.  They requested that win there's an arm squib resistance fault in arming that the user is notified of the error.
 
With the patch when the arm fails, there's a check for arm squib resistance fault, and if found then the user is notified with a warning like this;
 
 
the easiest way to test this is to set up a test with squibs make it all the way to the arm step, then cause the squibs to be out of tolerance on resistance.  The easiest way of doing that is just pull the squib plugs out of the SPT.
 
I only changed this behavior for SPT as this was the specific request, but it might be nice to include for TDAS as well.
 
this patch may need changes for DP 4.0 as I'm not sure APILogger.RaiseError() exists in DP 4.0.
 
This patch only covers warning the user about the issue, other requests from the zendesk are addressed by other manuscript tickets.
 
 
 Attachments: 
    DTM_36713_SquibWarn.patch 6.8 KB</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2024-01-04T22:04:59Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>now shows this warning;</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-01-04T17:50:10Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-01-04T00:10:16Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-01-03T19:23:38Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>##- Please type your reply above this line -##
 
You are a follower on this request (#12824, #dtsweb.zendesk.com/agent/tickets/12824). Reply to this email to add an internal note to the request.
 
 
 
          
Christopher Schmidt
 
Jan 3, 2024, 14:18 EST
 
 
 
·         When StatusArmSquibResistanceFault occurs, alert the user which module produced the fault
 
 
 
 
Also the Channel(s) at fault would be helpful
 
 
 
 
 
 
 
 
 
         
 
          
Nathan Brown (DTS)
 
Jan 3, 2024, 14:10 EST
 
Hi guys,
  
 More info about the squib resistance check...
  
 While the signal chain and measurement method is identical during Pre-Test Checklist and Arm states, the TOM power circuits are energized in between between the two steps. This causes current leak and a slight imprecision in measurement which firmware compensates for. After corrections, there is still a ~10% uncertainty.
  
 I am proposing these changes to DataPRO: 
 
Round Ohm readings to nearest 0.1 - down for low tolerance, up for high.
 
When StatusArmSquibResistanceFault occurs, alert the user which module produced the fault
 
  
 Another consideration is the squib resistance tolerances. I think it's good to have them tight enough to catch real issues. It may be worth considering opening them up a small amount if we find this particular test was actually ok to run as-is.
  
 Hope this helps. Feel free to call to discuss if easier. 810 772 0414
  
 Talk again soon!
 
 
         
 
          
Nathan Brown (DTS)
 
Jan 3, 2024, 13:44 EST
    Private note    
Great info, thank you Loc!
 
 
         
 
          
Loc Pham (DTS)
 
Jan 3, 2024, 13:05 EST
    Private note    
 
 
Hello @Nathan Brown,
 
 
 
Sorry I don’t have an exact number for error margin, but given the leakage of 20-30% and the work-around has been implemented in firmware to detect power present and compensate for the leakage bias current, I would say setting limit to +-10% would be safe? 
 
 
 
A few additional noise sources are externa ADC input/references, cap charging time, and stabilization time for leakage current (as caps being charged)….
 
 
 
We will be working on an issue with digital output (ticket##9898) and look into this issue see if any improvements.
 
 
 
Thanks,
  
 
 
 
 
 
 
                                                                                              Loc Pham​   Firmware Engineering Department Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     loc.pham@dtsweb.com     |         o:     +1 562 493 0158 x134     |     www.dtsweb.com                                       CONFIDENTIALITY: This email and any attachments may contain information from Diversified Technical Systems, Inc. (DTS) which​ is confidential ​and/or proprietary. If you received this transmission in error, any use, reproduction or dissemination of this transmission​ is strictly prohibited. ​Please delete this message and notify sender immediately.  
 ​EXPORT CONTROL NOTICE: This e-mail may contain technical data whose export, transfer, and/or disclosure may be controlled by​ the US ​International Traffic in Arms Regulation (ITAR) 22 CFR part 120-130 or the Export Administration Regulations (Commerce).
 ​
 ​                                  
 
 
 
 
 
         
 
          
Nathan Brown (DTS)
 
Jan 3, 2024, 12:20 EST
    Private note    
Thank you for the details, Loc Pham !
   
 
Is the error margin consistent? For instance, can we apply a 1.2 factor when reporting resistance, depending on the power mode? I agree there is some margin of error that must be tolerated by the customer. I want to make the experience consistent and not surprise late in the test.
 
  
 We can open the tolerance, and that may be ok in the longer run, but Nissan decided it best to abort the test and double check cabling instead. Good precaution!
  
  
 
 
         
 
          
Loc Pham (DTS)
 
Jan 3, 2024, 11:48 EST
    Private note    
 
 
Hello @Nathan Brown,
 
 
 
 
SPT measures resistance using the same signal path, however, the HW design has some current leaks that can cause up to 20%-30% error. However, I found a work-around to compensate for this issue.  The difference in measurement is when the power to squib is on and off state. What is the error margin set to the test? There’s a way you can check is to measure resistance with FWTU in low power mode and with power on (PrepareForDiagnostics)
 
 
 
 
 
I agree, we should round up to 1 decimal instead of sending back those many and may mislead user about the accuracy.
 
 
 
 
Can you open up the limits a little more?
 
 
 
Thanks,
 
 
 
Loc
 
 
 
 
                                                                                              Loc Pham​   Firmware Engineering Department Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     loc.pham@dtsweb.com     |         o:     +1 562 493 0158 x134     |     www.dtsweb.com                                       CONFIDENTIALITY: This email and any attachments may contain information from Diversified Technical Systems, Inc. (DTS) which​ is confidential ​and/or proprietary. If you received this transmission in error, any use, reproduction or dissemination of this transmission​ is strictly prohibited. ​Please delete this message and notify sender immediately.  
 ​EXPORT CONTROL NOTICE: This e-mail may contain technical data whose export, transfer, and/or disclosure may be controlled by​ the US ​International Traffic in Arms Regulation (ITAR) 22 CFR part 120-130 or the Export Administration Regulations (Commerce).
 ​
 ​                                  
 
 
 
 
 
         
 
          
Nathan Brown (DTS)
 
Jan 3, 2024, 10:06 EST
    Private note    
Hi Loc Pham  
 
 Nissan ran a test in DataPRO with SPT where a squib measured 3.469053 during Arm Checklist which passed the 3.5 ohm upper tolerance, then threw StatusArmSquibResistanceFault when armed.
 
 2 questions:
 
 1. Does SLICE PRO TOM squib resistance check QuerySquibResistance use the same signal chain and comparison method as the resistance check that happens once armed? I remember MB describing the TDAS PRO TOM has an analog comparator that may be slightly different, but SPT uses the ADC...
 
 2. Do we know the precision of the resistance measurement? For instance 3.46953 seems like a lot of digits. I think rounding to hundredths is more than enough?
  
 Any other thoughts?
 
 
         
 
          
Nathan Brown (DTS)
 
Jan 3, 2024, 10:00 EST
 
Chris Schmidt reported an issue on a barrier test today at Nissan where everything checked out pre-test but DataPRO would error when arming. There were no message boxes indicating why.
  
 We found that the squib resistance on port 4 of SPS00238 measured 3.469 Ω during Pretest Checklist, with an upper tolerance set to 3.5 Ω. 
  
 During the arm state, the SPT module continually monitors the squib resistances, and reported back StatusArmSquibResistanceFault-- possibly caused by temperature influence since arm checklist, or noise on the lines changing the reading by 0.03 ohms.
  
 Ultimately, I believe DataPRO operated correctly, preventing a fringe squib circuit from running in a full scale test. 
  
 We can make this smoother.
  
 Some thoughts: 
 
DataPRO should alert the user of the error which caused the arm failure, and details about the module.
 
What is the real precision of the measurement? For instance, firmware reports 3.469053 but should we round to 3.47? 3.5?
 
Perhaps to help reliably pass/fail resistance checks, rounding up must not exceed the upper tolerance and rounding down must exceed the low tolerance check.
 
DataPRO 4 adds a squib resistance check option to Run Test which allows us to test squib resistances further upstream. Looking at these details, I don't believe this would make any difference.
 
  
  
 Notes from the logs...
  
 In the log during arming, we see: 

2024-01-02 15:14:28.206 !!  An exception of type: System.Exception occurred Module: ICommand.dll, Name: InternalSyncExecuteMessage: SPT00238 was executing  DTS.DASLib.Command.SLICE.Arm   and reported SyncExecute: response.Status = StatusArmSquibResistanceFault for sequence 43101\43101.  Please report this information to Technical Support StackTrace:    at DTS.DASLib.Command.AbstractCommandBase.InternalSyncExecute() StackTrace:    at DTS.DASLib.Command.AbstractCommandBase.SyncExecute()    at DTS.DASLib.Service.Slice`1.AsyncPreparedArm(Object asyncInfo)
  
 previously, we see that channel 4 is likely the culprit: 

2024-01-02 15:12:21.251 -&gt; Diagnostics - SetSquibChannelConfiguraion [00039533], SPT00238, local: 10.81.229.110:58971, Remote: 10.81.229.70:1017 Channel: 3, Firemode: 1, MeasurementType: 1, Delay: 52, Duration: 10, OutputCurrent: 1.5, ResistanceLow: 2, ResistanceHigh: 3.5

2024-01-02 15:13:11.079 -&gt; Diagnostics - QuerySquibResistance [00040919], SPT00238, local: 10.81.229.110:58971, Remote: 10.81.229.70:1017
2024-01-02 15:13:11.127 &lt;- Diagnostics - QuerySquibResistance [00040919]\[00040919] - (46.6862ms), SPT00238 Measured Resistance (ohms): (2.922063, 2.589856, 2.566835, 3.469053)
2024-01-02 15:13:11.127 SPT00238 has completed service DiagnosticsService
  
  
  
  
 
 
         
 
----------------------------------------------
 Customer Details:
 Name: Christopher Schmidt ( christopher.schmidt@nissan-usa.com )
 Organization: Nissan (NA)
 
----------------------------------------------
 If you no longer wish to see notifications for this ticket, please use the 'Unfollow' option in the Followers List.
 
 
You are an agent. Add a comment by replying to this email or view ticket in Zendesk Support.
    Ticket # 12824   Status Open   Requester Christopher Schmidt   CCs Terry Charles   Followers Chad J Ivan, Chris Balogh, Dan McFadden, Loc Pham   Group Support   Assignee Nathan Brown   Priority Normal   Type Problem   Channel Web Form    
 
 This email is a service from DTS. Delivered by Zendesk.
 
 [PGP90Z-KEDPL]Ticket-Id:12824Account-Subdomain:dtsweb</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2024-01-03T19:23:38Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>