<?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-01-02T16:18:55Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-10-20T15:35:14Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>verified datapro can export ch10  files with and without secondary header ...
Files can be opened and viewed in netview  similar to subscribing to a data stream.

</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2023-10-20T15:34:08Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-10-12T21:57:17Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-09-27T21:36:42Z</TimeStamp>
    <ReleaseNote>Addresses various CH10 export issues (secondary time header and spaces in TMATS)</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-09-27T21:36:04Z</TimeStamp>
    <ReleaseNote>Addresses various CH10 export issues</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.1/4.2@49592</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-09-15T21:31:21Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>data tested with is here for reference:
 
\\dts\files\Software\Private\Useful_Test_Files\DataPRO\Data\MS33199.7z</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-09-15T21:30:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-09-15T21:15:21Z</TimeStamp>
    <ReleaseNote>Addresses a couple of CH10 export issues</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>it might be difficult for SQA to test this without writing code.  There is a tool to parse the ch10 file though...</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-09-15T21:14:44Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>Recorded Data:
 
 
 
 
-1s -&gt; 5s. EU -900-&gt;1800
 
 
 
CSV shows same thing, but with UTC time as well;
 
 
 
 
 
 
Time goes from
 
     
2023/09/14 23:37:10:494400248
     
 
To
 
     
2023/09/14 23:37:16:494400248
     
 
Or 6 seconds
 
In netview
 
 
 
 
It appears to go from 23:37:10.494 to 23:37:16:494
 
The plots appears to have a maybe 2400 EU offset for some reason.
 
Looking at time secondary header time packets I see this for nanoseconds and seconds:
 
 
 
This roughly matches my expectations
 
(packet 0 is setup file, packet 1 time packet, packet 2 analog data, packet 3 time packet, packet 4 data packet….)
 
 
 
 
If I look at all packets and  the RTC value I see a similar pattern
 
 
 
 
If I look at the packet length field
 
 
 
 
They seem to be divisible by 4
 
 
 
Looking at the TMATS data, the only area that has a space now is R-1\RI4, as datetime
 
G\PN:DataPRO_1.06.00081;
 
G\TA:MS33199;
 
G\106:17;
 
G\DSI\N:1;
 
G\DSI-1:PTP;
 
G\DSI-2:MS33199;
 
G\DST-1:DRS;
 
G\DSC-1\U;
 
G\SC\U;
 
G\COM:--- DTS Analog Time format 2 file export -----;
 
R-1\ID:MS33199;
 
R-1\RID:S6ACH6;
 
R-1\N:2;
 
R-1\NSB:0;
 
R-1\RI1:DTS;
 
R-1\RI2:S6A;
 
R-1\RI3:Y;
 
R-1\RI4:2023-09-15 19:04:33;
 
R-1\COM:Ver-17;
 
V-1\ID:MS33199;
 
V-1\VN:DTS;
 
V-1\DTS\STREAMCH10;
 
R-1\EV\E:F;
 
R-1\IDX\E:F;
 
R-1\IDX\IT:F;
 
R-1\COM:--- Channel '1', ID: 0x0001, TIME Data Packet Format ---------------;
 
R-1\TK1-1:1;
 
R-1\TK2-1:OTHER;
 
R-1\DSI-1:1;
 
R-1\TK3-1:FWD;
 
R-1\TK4-1:1;
 
R-1\CHE-1:T;
 
R-1\CDT-1:TIMEIN;
 
R-1\CDLN-1:1;
 
R-1\TTF-1:2;
 
R-1\TFMT-1:B;
 
R-1\TSRC-1:E;
 
R-1\SHTF-1:1;
 
R-1\COM:--------------------- Main Analog Channel Description --------------;
 
R-1\DSI-2:3;
 
R-1\TK1-2:3;
 
R-1\TK2-2:OTHER;
 
R-1\TK3-2:FWD;
 
R-1\TK4-2:3;
 
R-1\CHE-2:T;
 
R-1\CDLN-2:DTS_CH10_Export;
 
R-1\CDT-2:ANAIN;
 
R-1\ATF-2:1;
 
R-1\ACH\N-2:6;
 
R-1\ADP-2:NO;
 
R-1\ASR-2:10000;
 
R-1\SHTF-2:1;
 
R-1\COM:--------------------- Start of channels ---------------------;
 
R-1\COM:--------------------- Subchannel_1 Description ---------------------;
 
R-1\AMCE-2-1:T;
 
R-1\AMCN-2-1:1;
 
R-1\AMN-2-1:Channel_0001;
 
R-1\ADL-2-1:16;
 
R-1\AMSK-2-1:FW;
 
R-1\AMTO-2-1:M;
 
R-1\ASF-2-1:0;
 
R-1\ASBW-2-1:200;
 
R-1\ACP-2-1:D;
 
R-1\AII-2-1:50;
 
R-1\AGI-2-1:100;
 
R-1\AFSI-2-1:5000;
 
R-1\AOVI-2-1:2500;
 
R-1\ALSV-2-1:19;
 
R-1\AECU-2-1:1;
 
R-1\AF-2-1:U;
 
R-1\AIT-2-1:S;
 
R-1\AV-2-1:N;
 
R-1\AECO-2-1:0;
 
R-1\AECS-2-1:0.0775081068277359;
 
C-1\DCN:Channel_0001;
 
C-1\MN1:Channel_0001;
 
C-1\BFM:UNS;
 
C-1\DCT:COE;
 
C-1\CO\N:1;
 
C-1\MN3:g_;
 
C-1\MOT1:1814.69730515778;
 
C-1\MOT3:1814.69730515778;
 
C-1\MOT5:1814.69730515778;
 
C-1\MOT2:-907.929963380098;
 
C-1\MOT4:-907.929963380098;
 
C-1\MOT6:-907.929963380098;
 
R-1\COM:--------------------- Subchannel_1 End ---------------------;
 
R-1\COM:--------------------- Subchannel_2 Description ---------------------;
 
R-1\AMCE-2-2:T;
 
R-1\AMCN-2-2:2;
 
R-1\AMN-2-2:Channel_0002;
 
R-1\ADL-2-2:16;
 
R-1\AMSK-2-2:FW;
 
R-1\AMTO-2-2:M;
 
R-1\ASF-2-2:0;
 
R-1\ASBW-2-2:200;
 
R-1\ACP-2-2:D;
 
R-1\AII-2-2:50;
 
R-1\AGI-2-2:100;
 
R-1\AFSI-2-2:5000;
 
R-1\AOVI-2-2:2500;
 
R-1\ALSV-2-2:19;
 
R-1\AECU-2-2:1;
 
R-1\AF-2-2:U;
 
R-1\AIT-2-2:S;
 
R-1\AV-2-2:N;
 
R-1\AECO-2-2:0;
 
R-1\AECS-2-2:0.0774645209312439;
 
C-2\DCN:Channel_0002;
 
C-2\MN1:Channel_0002;
 
C-2\BFM:UNS;
 
C-2\DCT:COE;
 
C-2\CO\N:1;
 
C-2\MN3:g_;
 
C-2\MOT1:1815.14865446091;
 
C-2\MOT3:1815.14865446091;
 
C-2\MOT5:1815.14865446091;
 
C-2\MOT2:-907.96164983511;
 
C-2\MOT4:-907.96164983511;
 
C-2\MOT6:-907.96164983511;
 
R-1\COM:--------------------- Subchannel_2 End ---------------------;
 
R-1\COM:--------------------- Subchannel_3 Description ---------------------;
 
R-1\AMCE-2-3:T;
 
R-1\AMCN-2-3:3;
 
R-1\AMN-2-3:Channel_0003;
 
R-1\ADL-2-3:16;
 
R-1\AMSK-2-3:FW;
 
R-1\AMTO-2-3:M;
 
R-1\ASF-2-3:0;
 
R-1\ASBW-2-3:200;
 
R-1\ACP-2-3:D;
 
R-1\AII-2-3:50;
 
R-1\AGI-2-3:100;
 
R-1\AFSI-2-3:5000;
 
R-1\AOVI-2-3:2500;
 
R-1\ALSV-2-3:19;
 
R-1\AECU-2-3:1;
 
R-1\AF-2-3:U;
 
R-1\AIT-2-3:S;
 
R-1\AV-2-3:N;
 
R-1\AECO-2-3:0;
 
R-1\AECS-2-3:0.0772473439574242;
 
C-3\DCN:Channel_0003;
 
C-3\MN1:Channel_0003;
 
C-3\BFM:UNS;
 
C-3\DCT:COE;
 
C-3\CO\N:1;
 
C-3\MN3:g_;
 
C-3\MOT1:1815.0808409676;
 
C-3\MOT3:1815.0808409676;
 
C-3\MOT5:1815.0808409676;
 
C-3\MOT2:-907.501796811819;
 
C-3\MOT4:-907.501796811819;
 
C-3\MOT6:-907.501796811819;
 
R-1\COM:--------------------- Subchannel_3 End ---------------------;
 
R-1\COM:--------------------- Subchannel_4 Description ---------------------;
 
R-1\AMCE-2-4:T;
 
R-1\AMCN-2-4:4;
 
R-1\AMN-2-4:Channel_0004;
 
R-1\ADL-2-4:16;
 
R-1\AMSK-2-4:FW;
 
R-1\AMTO-2-4:M;
 
R-1\ASF-2-4:0;
 
R-1\ASBW-2-4:200;
 
R-1\ACP-2-4:D;
 
R-1\AII-2-4:50;
 
R-1\AGI-2-4:100;
 
R-1\AFSI-2-4:5000;
 
R-1\AOVI-2-4:2500;
 
R-1\ALSV-2-4:19;
 
R-1\AECU-2-4:1;
 
R-1\AF-2-4:U;
 
R-1\AIT-2-4:S;
 
R-1\AV-2-4:N;
 
R-1\AECO-2-4:0;
 
R-1\AECS-2-4:0.0765502601861954;
 
C-4\DCN:Channel_0004;
 
C-4\MN1:Channel_0004;
 
C-4\BFM:UNS;
 
C-4\DCT:COE;
 
C-4\CO\N:1;
 
C-4\MN3:g_;
 
C-4\MOT1:60.1685045063496;
 
C-4\MOT3:60.1685045063496;
 
C-4\MOT5:60.1685045063496;
 
C-4\MOT2:-32.3807600587606;
 
C-4\MOT4:-32.3807600587606;
 
C-4\MOT6:-32.3807600587606;
 
R-1\COM:--------------------- Subchannel_4 End ---------------------;
 
R-1\COM:--------------------- Subchannel_5 Description ---------------------;
 
R-1\AMCE-2-5:T;
 
R-1\AMCN-2-5:5;
 
R-1\AMN-2-5:Channel_0005;
 
R-1\ADL-2-5:16;
 
R-1\AMSK-2-5:FW;
 
R-1\AMTO-2-5:M;
 
R-1\ASF-2-5:0;
 
R-1\ASBW-2-5:200;
 
R-1\ACP-2-5:D;
 
R-1\AII-2-5:50;
 
R-1\AGI-2-5:100;
 
R-1\AFSI-2-5:5000;
 
R-1\AOVI-2-5:2500;
 
R-1\ALSV-2-5:19;
 
R-1\AECU-2-5:1;
 
R-1\AF-2-5:U;
 
R-1\AIT-2-5:S;
 
R-1\AV-2-5:N;
 
R-1\AECO-2-5:0;
 
R-1\AECS-2-5:0.0774122849106789;
 
C-5\DCN:Channel_0005;
 
C-5\MN1:Channel_0005;
 
C-5\BFM:UNS;
 
C-5\DCT:COE;
 
C-5\CO\N:1;
 
C-5\MN3:g_;
 
C-5\MOT1:86.6243468150496;
 
C-5\MOT3:86.6243468150496;
 
C-5\MOT5:86.6243468150496;
 
C-5\MOT2:-41.9574584215879;
 
C-5\MOT4:-41.9574584215879;
 
C-5\MOT6:-41.9574584215879;
 
R-1\COM:--------------------- Subchannel_5 End ---------------------;
 
R-1\COM:--------------------- Subchannel_6 Description ---------------------;
 
R-1\AMCE-2-6:T;
 
R-1\AMCN-2-6:6;
 
R-1\AMN-2-6:Channel_0006;
 
R-1\ADL-2-6:16;
 
R-1\AMSK-2-6:FW;
 
R-1\AMTO-2-6:M;
 
R-1\ASF-2-6:0;
 
R-1\ASBW-2-6:200;
 
R-1\ACP-2-6:D;
 
R-1\AII-2-6:50;
 
R-1\AGI-2-6:100;
 
R-1\AFSI-2-6:5000;
 
R-1\AOVI-2-6:2500;
 
R-1\ALSV-2-6:19;
 
R-1\AECU-2-6:1;
 
R-1\AF-2-6:U;
 
R-1\AIT-2-6:S;
 
R-1\AV-2-6:N;
 
R-1\AECO-2-6:0;
 
R-1\AECS-2-6:0.0767875015735626;
 
C-6\DCN:Channel_0006;
 
C-6\MN1:Channel_0006;
 
C-6\BFM:UNS;
 
C-6\DCT:COE;
 
C-6\CO\N:1;
 
C-6\MN3:g_;
 
C-6\MOT1:109.038252234459;
 
C-6\MOT3:109.038252234459;
 
C-6\MOT5:109.038252234459;
 
C-6\MOT2:-52.2922885715961;
 
C-6\MOT4:-52.2922885715961;
 
C-6\MOT6:-52.2922885715961;
 
R-1\COM:--------------------- Subchannel_6 End ---------------------;
 
R-1\COM:--------------------- End of channels ---------------------;
 
R-1\COM:--------------------- End of TMATS ------------
 
 
 
Looking at the data as parsed out from the export file using our own parser, it's not surprisingly an exact match to the CSV export from dataPRO:</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-09-15T20:51:55Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-09-14T23:17:39Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-09-14T23:14:56Z</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 (#10690, #dtsweb.zendesk.com/agent/tickets/10690). Reply to this email to add an internal note to the request.
 
 
 
          
Maugan Robert (DTS)
 
Sep 14, 2023, 11:48 GMT+2
 
Dan - in addition to the other issues and waiting for your new export, I have another request from Dassault, which I first thought was not a legitimate request, but actually it seems to be one.
  
 They refer to Chapter9 doc (cf attached), in section 9.4.2. to request that we get rid of any blank space in the channel names and other fields "leading, trailing, and embedded blanks [...] should not be used in code names, keywords, and data itmes used as links, such as measurement name."
 Chapter9 is the reference document for the TMATS definition.
 They suggest that we replace them with "_".
 They noticed blank spaces in R-x\AMN-n-m and C-x\DCN of the TMATS (channel names).
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 chapter9.pdf
         
 
          
Dan McFadden (DTS)
 
Sep 13, 2023, 18:59 GMT+2
    Private note    
 
will do
 
 
                                                                                              Dan McFadden​   Software Engineering Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     dan.mcfadden@dtsweb.com     |         o:     +1 562 493 0158 x137     |     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).
 ​
 ​                                  
 On 9/13/2023 9:35 AM, Maugan Robert (DTS) wrote:
 
 
 
         
 
          
Maugan Robert (DTS)
 
Sep 13, 2023, 18:35 GMT+2
 
Dan - good question, you did the export on June 9th, not me :)
  
 Considering the date of the build (8/23), I'd assume it was made with an older version. In your Next software sprint email from 5/24, you mention FB#30509 for Dassault ch10 export that will be worked on in the next sprint (4.1.20).
 Also, the ch10 file says "DataPRO 1.06.00081", not sure it means anything.
  
 Could you redo an export of the same recording with the latest 4.1 build available to share with Dassault and see what has been solved yet?
  
 Thx!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 13, 2023, 18:26 GMT+2
    Private note    
 
sure.
 
This sounds like it was from an old export though
 
was it exported with atleast 4.1.421?  There's been a bunch of work to verify this for telspan and netview already ... and notably we do make sure the packet length is a multiple of 4 ... chances are this was from an old export ...
         
Dashboard &gt; local &gt; DATAPRO &gt; DATAPRO_MAINT_4_01 &gt; 2023-08-23 09:05:58 (4.1.421.49423)
       
Version : 1.8.5.0
                   Latest   Next   Previous       Build Report   View Build Log           Recent Builds   2023-09-13 09:21:28 (Failed)   2023-09-13 09:17:12 (Failed)   2023-09-13 09:10:58 (Failed)   2023-09-13 09:04:43 (Failed)   2023-09-13 08:58:28 (Failed)   2023-09-13 08:52:11 (Failed)   2023-09-13 08:45:58 (Failed)   2023-09-13 08:39:41 (Failed)   2023-09-13 08:33:26 (Failed)   2023-09-13 08:27:12 (Failed)       Show All                      BUILD SUCCESSFUL   Project: DATAPRO_MAINT_4_01   Date of build: 2023-08-23 09:05:58   Running time: 00:11:44   Integration Request: Build (IfModificationExists) triggered from IntervalTrigger   Last changed: 2023-08-23 08:52:22   Last log entry: 33048 Prove CH10 export data matches streamed data on S6A FB33048              
 
 
 
                                                                                              Dan McFadden​   Software Engineering Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     dan.mcfadden@dtsweb.com     |         o:     +1 562 493 0158 x137     |     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).
 ​
 ​                                  
 On 9/13/2023 9:18 AM, Maugan Robert (DTS) wrote:
 
 
 
         
 
          
Maugan Robert (DTS)
 
Sep 13, 2023, 18:18 GMT+2
 
Hi Dan,
  
 After changing the person who was working on this topic, Dassault came back to me with a list of issues in the latest ch10 export format.
 Here are the details based on the last recording you provided below on June 9th:
   
 
Header indicates wrong packet size: the header of the first packet which includes the TMATS indicates the following: 
 
Packet size: 6154 bytes
 
Data size: 6127 bytes 
 
The packet size can't be divided by 4, which is a requirement of the chapter 11 standard (cf 11.2.1.1.c): "These 4 bytes contain a value representing the length of the entire packet. The value shall be in bytes and is always a multiple of four (bit 1 and bit 0 shall always be zero)"
 
The size of the packet with a secondary header is 36 bytes (24 for the primary header and 12 for the secondary header). So, the Data size is a wrong value (6154 - 36 = 6118 bytes, not 6127). Looking at the data packet, its real size is 6115 bytes plus 3 padding bytes. Dassault suggested to define the data size to 6115 plus only one padding byte which sums up to a packet size of 6152 bytes.
 
 
 
 
 
Timestamp of secondary headers is invalid: 
 
For every other packet (1 on 2, analog packets only), the timestamp encoded in the secondary header is higher than what it should be. They have put all time sources on the same graph (RTC value, time packet value and secondary header). It clearly shows that the secondary header of the time packets is identical to the RTC and the time packet value, but that the one of the analog packets is growing two times more than expected:
 
 
 
  
 
  
 Zoom on a few packets:
 
  
 The RTC time was corrected as it was absolute, to match the other timings.
  
 Is it possible to have a look at this whenever possible (when you have time or in the next sprint)?
  
 Thanks!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Jun 23, 2023, 15:52 GMT+2
    Private note    
 
I believe Chapter 11 will have more detail in 11.2.3.3 Time Data Packets, Format 2 (Network Time)
 
Attached
 
 
 
 
                                                                                              Dan McFadden​   Software Engineering Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     dan.mcfadden@dtsweb.com     |         o:     +1 562 493 0158 x137     |     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).
 ​
 ​                                  
 On 6/23/2023 1:59 AM, Maugan Robert (DTS) wrote:
 
 
 
 
Attachment(s)
 chapter11.pdf
         
 
          
Maugan Robert (DTS)
 
Jun 23, 2023, 10:59 GMT+2
 
Dan,
  
 Thanks for the explanations and details, I really appreciate it!
 It definitely should help Dassault, and I understand why you switched from PCM to Analog format.
  
 Regarding the Time Format 2, could you share the chapter10 file you used as reference to develop this? Because in the 2015 Standard, the Time Format 2 does not exist (only 0/1, cf attachment page 53).
  
 Thx!
 Maugan
 
 
 
Attachment(s)
 chapter10.pdf
         
 
          
Dan McFadden (DTS)
 
Jun 22, 2023, 19:35 GMT+2
    Private note    
Hi Maugan,
  
 I decided to make use of what was available and currently in most demand for streaming for the S6A, which is CH 10 analog time format 2.
 
 this offers a higher efficiency, or more data versus overhead/headers for the other formats.
  
 PCM is still possible, but I wanted to make use of what would probably be of the most interest to streaming applications.  There's already been a proposal to hide the other stream formats other than analog time format 2 for now from the UI.
  
 http://manuscript.dts.local/f/cases/31840/hide-streaming-formats-other-than-Analog-Time-Format-2-by-default
  
 I've attached a document from f/w on the format
 I've also attached the pptx I gave from the demo on parsing out S6A EU values from streaming.  This might be a little bit simplified for their purposes, but I would expect they would be able to absorb it pretty easily.
  
 I think it's okay to send both of these, with any translation or updates needed.
  
 I also wrote an short application that I used to validate both the streams I had recorded off the ethernet data recorder, or parse out a S6A stream.  I also made a few adaptations to this application to read a CH10 export from DataPRO, and output a CSV of EU data that I then compared to the CSV export from DataPRO just to verify the data was coming across as expected.  These are the two CSV files you saw attached earlier in the thread, one was from DataPRO, one was from this helper application.  I'm more than happy to share this helper application too, but it's not a released application and there's no manual and with no warranties, it was just a simple tool to compare the two outputs and to use in the demo.
  
 This at least shows the mechanisms in use for validating the Checksums, etc, but those are in the pptx as well, usually with both c# and C code.  The solution file is S6AAnalogStreamDecoder.sln
  
 The only difference between the streamed version and the exported version are the present of transport headers, the streamed version includes transport headers while the export version does not.  This can be turned on or off in the code via this line.  //#define NO_TRANSPORT_HEADERS  when this macro is defined it will not look for transport headers.
  
 there's also some code that makes assumptions, but I don't expect them to actually be interested in running the code, I think the documents will probably cover everything they need.
  
  
 
 
 
Attachment(s)
 Analog With Time Format 2 Packet Format.docx
 CH10AnalogTimeFormat2.pptx
 S6AAnalogStreamDecoder.7z
         
 
          
Maugan Robert (DTS)
 
Jun 22, 2023, 19:00 GMT+2
 
Hi Dan,
  
 Quick feedback/questions from Dassault: 
 
Have we moved away from the PCM Data Packet format, to now use the Analog Data Packet format?
 
The Time Data, Format 2 wasn't in the 2015 ch10 Standard. They ask if this format is usable on the long-term, as they seem to be used to Format 1... I guess it is, but better to confirm :)
 
Could you share the documentation you based your development on, to get all the details on the Standard?
 
  
 Thanks!
 Maugan
 
 
         
 
          
Maugan Robert (DTS)
 
Jun 20, 2023, 12:35 GMT+2
    Private note    
Dan - looking at all the FB entries related to this ticket, I assume you have created these ch10 export files with DP 4.1.2X, am I right?
 When will this version be released/available?
  
 What do you mean by decoder utility? The first CSV file you attached seems to be the CSV export without the header. Not sure it is useful, unless I'm missing something - if so please help me understand! :)
  
 I'll send the files to Dassault and wait for their feedback.
  
 Thanks!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Jun 9, 2023, 23:54 GMT+2
    Private note    
updated with a CH10 file exported from DataPRO in CH10 analog time format 2, with an accompanying CSV exports from datapro and a decoder utility.
 
 
 
Attachment(s)
 638219178916185703.CSV
 2023_05_05 12_33_UNF.ch10
 2023_05_05 12_33_Event Number 01.csv
         
 
          
Dan McFadden (DTS)
 
May 12, 2023, 01:26 GMT+2
    Private note    
Hi Maugan,
  
 I set up a S6A to stream and record in place with CH10 analog time format 2.  Simultaneously I set up an Ethernet Data Recorder to record the stream from the S6A.  I wanted to do this so I could model the export in datapro after the streaming done with the S6A since that seems to be accepted at this point.  I then opened the recorded dataset that was recorded and exported it using the same formats used by the stream by comparing what was collected by the EDR.
  
 I've attached two such exports, Output.CH10 and OutputNoTS.CH10.  The S6A streams with transport stream bytes ahead of datapackets, which I don't think should be in the CH10 file.  The OutputNoTS.CH10 is the file they would be interested in I think, although I attached both one with a transport header and one without.  I didn't bother filling in the transport bytes with meaningful information as I don't think it's needed.
  
 I've attached loc's diagram of his CH10 stream here just as a reference on the transport stream bytes.
 
  
  
 I've also attached S6A0063.bin, this file is the all the raw packets sent in the stream as received and recorded on the EDR, for reference.
  
 I then made sure that the packets used the same CRC methods on headers by validating both the exported packets and streamed packets, including the packet header CRC and the secondary time header CRC.  The analog data packets themselves did not have a data CRC, so I preserved this behavior.
  
 I then used the same code to graph both the stream and export together against each other in EU.
  
 here is the data displayed in DataPRO as recorded on the S6A:
 
  
 here's all 3 methods overlapped with each other:
 
  
 the top graph is from the export of the recorded data, the second graph is the graph as viewed from the DTS file and chn file directly, and the 3rd graph is a view of the data by decoding the streamed data in the .bin file.
  
 there is a secondary time header included in all the packets, which is in seconds and nano seconds.  The first time is determined using the nano seconds and seconds for the trigger as recorded in the .dts file and then using the sample rate and number of samples to determine the starting time.  Each following secondary time header is based on the sample rate and number of samples.
  
 EU scaling was done by using the CO-1 entries in the TMATS file.
  
 In the actual streamed data the plot uses the actual time headers in the stream.
  
 I've also attached the dataset used in the sample for reference.
  
 are they able to use this export at all?  If they are parsing the streamed out data from the S6A in CH10 analog time format 2 then there's a good chance this will match what they are using in the stream.
  
 
 
 
Attachment(s)
 OutputNoTS.CH10
 Output.CH10
 S6A0063.bin
 StreamAndRecord.zip
         
 
          
Chris Balogh (DTS)
 
Apr 6, 2023, 19:14 GMT+2
 
Maugan Robert ,
  
 Thank you for confirming. These will be included in the 4.1 release.
 
 
         
 
          
Maugan Robert (DTS)
 
Apr 6, 2023, 19:03 GMT+2
 
Chris - Then I think it should be all good with these four things.
  
 Maugan
 
 
         
 
          
Chris Balogh (DTS)
 
Apr 6, 2023, 18:16 GMT+2
 
Maugan Robert ,
  
 That's the thing to capture here. Currently, from this ticket I've got four tasks identified.
 
 
 
         
 
          
Maugan Robert (DTS)
 
Apr 6, 2023, 15:37 GMT+2
 
Chris,
  
 Thank you for the feedback on the stakeholders meeting.
 Let me know if any info is needed from the customer to implement/solve the different aspects of what is required for a proper ch10 export.
  
 Putting this ticket on-hold for now.
  
 Thanks!
 Maugan
 
 
         
 
          
Chris Balogh (DTS)
 
Apr 5, 2023, 21:04 GMT+2
 
All,
  
 Decision from Stakeholders was to extend the date on 4.1 (TBD; Q4 '23?) and add in the time needed to complete Ch10 Export needs for Dassault.
  
 It was also noted that this feature update/maintenance would benefit more than just Dassault. This feature has benefits for all A&amp;D customers.
  
 MS Parent Case: http://manuscript.dts.local/f/cases/30505/Parent-Dassault-DataPRO-chapter10-export-Need-info-details
 
 
         
 
          
Maugan Robert (DTS)
 
Apr 4, 2023, 19:47 GMT+2
 
Hi Chris,
  
 As far as I know, right now, they handle data through CSV export, which is a pain for their long recordings (hours).
 All other FTI they have exports data in ch10 format properly and they expect the SLICE6 AIR to do the same, which would save them a lot of time/effort on every recording.
  
 I hate to say this, but yes, they can live with what they have right now. It will just keep increasing their daily frustration when using the product, which may lead to them not buying DTS again for future projects.
  
 I have made them aware of our Software team workload and that it will take additonnal months to provide them with a proper solution. They understand that, but it doesn't mean this allows us to delay this until 2024.
 Also, they don't bother using a non-ECO version of DataPRO, so we should go in favor of whatever option gives them a solution the soonest and is acceptable for everybody around the table.
  
 Thanks!
 Maugan
 
 
         
 
          
Chris Balogh (DTS)
 
Mar 31, 2023, 20:00 GMT+2
 
Hi Maugan,
  
 CC Daniel Stelung  , Mike Beckage 
  
 This will always come down to priority. As of today SW is booked through the 4.1 release in Q3 (for complete SQA and ECO efforts) this year.
  
 We'll need to know where this lies in the grand scheme of other items we need to work on.
  
 4.2 is the next major release that will receive an ECO.
  
 There are always options, but like Dan said "Anytime comes at the expense of something else."
   
 
Wait for the 4.2 release in Q3 '24
 
Extend the date on 4.1 (TBD; Q4 '23?) and add in the time needed to complete Ch10 Export needs for Dassault.
 
Wait until after 4.1 is released as is, and then have the Ch10 Export worked on for an interim, SDR release of a 4.2 build (TBD; Q4 '23?) with Ch10 export work to Dassault only. This would iterate current 4.2 plan to be 4.3.
 
De-prioritize work being done on existing 4.1 plan to move in work on Ch10 Export for Dassault.
 
  
 What is Dassault's realistic expectation for a resolution to their CH10 Export issues? Are they dead in the water without SW efforts?
 
 
         
 
          
Dan McFadden (DTS)
 
Mar 28, 2023, 16:07 GMT+2
    Private note    
4.2 should finish on the software side around may 2024.
  
 There are no resources and no time.  I'm already here from 6:30AM to 5:30PM.  Everyone in my department is fully allocated.  Anytime comes at the expense of something else.
 
 
         
 
          
Maugan Robert (DTS)
 
Mar 28, 2023, 09:42 GMT+2
 
Dan - pending your answer on 4.2, are we sure we want to deal with this via the sprint workflow? Since it depends on the customer's expectation(s), we should work step by step with the customer rather than implement something in a sprint, release it, have the customer give feedback and then lose another several months to correct it again in another sprint when time is available.
  
 Thanks!
 Maugan
 
 
         
 
          
Maugan Robert (DTS)
 
Mar 27, 2023, 17:16 GMT+2
 
Dan - Thanks for the feedback. If 4.1 is due in May, when is 4.2 scheduled to be completed?
 
 
         
 
          
Dan McFadden (DTS)
 
Mar 27, 2023, 17:00 GMT+2
    Private note    
I have DP 4.1 which is supposed to be complete in May.  This is to include work for GM that is outstanding.  It includes  voltage insertion and UI updates that are outstanding.  Business development and sales want TSR AIR phase 3 features also included in that release as well.  There's S6A-Falcon-Id changes pending.  Additionally there's THF requests that need to be completed within a year.  I have zendesks with THF can't download from the SPS or has this SL6 with no data after T0 in this test.  Can I bump any of these for this item?
  
 I can not promise to have this item complete short of 4.2.  If this is acceptable we can include support for this in 4.2 with stakeholder approval.  Short of that I have a lack of options.
  
 
 
         
 
          
Mike Beckage (DTS)
 
Mar 27, 2023, 16:40 GMT+2
 
Dan - Thank you for all the effort you have put into this so far. Maugan would appreciate a realistic estimate of when the coming sprint is expected to result in a version that addresses their requests.
  
 Maugan - Sorry that we are short on resources to make faster progress. 
 
 
         
 
          
Dan McFadden (DTS)
 
Mar 27, 2023, 15:44 GMT+2
    Private note    
Hi Maugan,
  
 There are currently no resources to work on this.  The best I can do is try to reserve time in the coming sprint.  I apologize, but there just isn't anyone to work on this currently.
 
 
         
 
          
Maugan Robert (DTS)
 
Mar 17, 2023, 17:27 GMT+1
 
Hi Dan,
  
 I'm coming back on this as the customer has sent me multiple reminders since early February, which I haven't replied to as I was quite busy on other topics/travels.
  
 Could you please let me know if any progress has been made on the other items? If so, what can be share with Dassault and if not, when can we expect something?
  
 Thanks!
 Maugan
 
 
         
 
          
Maugan Robert (DTS)
 
Jan 31, 2023, 09:31 GMT+1
 
Hi Dan,
  
 Thanks for the feedback on the CRC.
 Have you had time to deal with the other listed items?
  
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Jan 11, 2023, 23:46 GMT+1
    Private note    
Hi Maugan - the easiest to get to was the CRC, so I got to that before I got switched to another task.
  
 I think we are using both 16 and 32 bit CRCs.  I changed the implementation of both.  I only changed the implementation of CRC16 and 32 in this export, both to strictly matching x-bit sum, everything else should be the same.  I think they only had an issue with the CRC32 output so if the 16 doesn't match anymore I can revert it.
  
 It should already only be considering data bytes and not header bytes.
  
 I understand the other items but did not have time to see if there's a specific reason why the date is always the same - I was expecting it to change with the exception of one reference RTC which we weren't changing - and the number of samples between time packets with the exception of the last one should also be constant, so I'm not sure why there would be 190 or 200 ms variation - I will need to check.
  
 
 
 
Attachment(s)
 2022_09_09 13_27_UNF.ch10
         
 
          
Maugan Robert (DTS)
 
Jan 5, 2023, 20:46 GMT+1
 
Hi Dan,
  
 Here is the feedback I got today from Dassault: 
 
Data checksum not matching: they suppose this is due to the calculation method. If you specify 32-bit checksum, then the ch10 definition says you should do the 32-bit arithmetic sum of words of channel-specific data only (not 1st/2nd headers). If you specify 16-bit checksum, it should do the 16-bit arithmetic sum of words , same for 8-bit checksum setting. See attached chapter10.pdf file on pages 10-29 and 10-32:
 
  
 
   
 
Time Packet (2nd one): in your example, the time is 3522/09/09 1:28pm, 42s 360ms. There is an issue with the year (at least)... :)
 
   
 
PCM packets: the date is always the same (5834 6A88 2381) for each frame, though it should be implemented of the initial time + delta_T * N_samples from the previous frame
 
   
 
Time difference between time packets: there is still 190ms or 200ms difference between time packets depending on where we look at in the ch10 file. There should always be the same time difference, not a different one.
 
  
 They also asked if we could provide a "longer" ch10 file with different channel packets separated by time packets. They told me usually the ch10 files are built like this: all channel packets are separated by one time packet every second.
  
 Let me know if you have any question or need anything else from me/them to work on this.
  
 The attached chapter10.pdf was provided by them as they told me they use it as their reference and it is the complete document compared to the one we posted in a previous post on this ticket which is a shorter version (57 pages compared to 198 for this one).
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 chapter10.pdf
         
 
          
Maugan Robert (DTS)
 
Dec 23, 2022, 16:09 GMT+1
 
Dan,
  
 Thanks for the work done. I've forwarded your answers to Dassault. As they are also closed next week, I don't expect any answer before 1st week of January.
  
 Merry Christmas and Happy New Year!! :)
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Dec 22, 2022, 23:48 GMT+1
    Private note    
Hi Maugan, 
  
 I made changes, but the resulting export file still does not validate, so I did not check in those changes nor build a new version.  I will attach the resulting export with a new log file as well.
  
 WRT to the 32-bit data checksum, I didn't see anything obvious wrong with the method, it just adds the bytes together, so more than likely the issue is there are bytes included in the checksum which are not expected.  I included all the bytes used in the checksum as well as the result in the log file - this should identify what the extra or missing bytes are.
  
 WRT data building issue - I changed it to only output a max of 250x16 bit samples per minor frame, which if I understand should create the 500 word per minor frame.  I now add all frames for 1 channel to one PCM packet resulting in some large PCM packets, but they follow 
  
 ITS ITH 90eb word1 word2 … word500 ITS ITH 90eb word1 word2 … word500
  
 as suggested in the pdf.  This also makes the final CRC a lot of bytes to check - I'm wondering if it would be OK to have a 1 frame per packet version to better look at the CRC issue, so I created a file and a log file using only 1 frame per PCM packet to maybe look at the CRC issue.
  
 if the CRC don't match expectation (which I would assume still be the case as I didn't change anything here), could they check the 1Frame .txt file and see what bytes they were expecting it to be calculated on versus what it was calculated on.
  
  
 
 
 
Attachment(s)
 2022_09_09 13_27_UNF.ch10
 2022_09_09 13_27_UNF_1FramePerPCM.ch10
 CH10Log.txt
 CH10Log_1FramePerPCM.txt
         
 
          
Dan McFadden (DTS)
 
Dec 22, 2022, 20:25 GMT+1
    Private note    
Hi Maugan,
 I'll look at the issue today - I read the Data building issue.pdf and it makes sense and I agree we are not outputting according to spec.
 
 
         
 
          
Maugan Robert (DTS)
 
Dec 22, 2022, 17:21 GMT+1
 
Dan - I assume you are quite busy, but could you look at this one please? Dassault just asked me about the status of this topic/issue.
  
 Thanks!
 Maugan
 
 
         
 
          
Maugan Robert (DTS)
 
Dec 14, 2022, 15:24 GMT+1
 
Hi Dan,
  
 Back on this one, I got some feedback from Dassault.
  
 First thing first, here is a tool they use to read ch10 files: Link to download (click on "Télécharger" to download, sorry for the French!)
 I get an error when I try to open one of our files... not sure if the problem is on my side or on the tool side.
  
 Then, here are the issues they have found in the .ch10 file we provided: 
 
The first packet is "Computer Generated" with a 32bits data checksum at the end, according to the header. However, the last bits "979f a700 does not match the addition of all words of the packet.
 
 
 
25eb 0000
 
 
 
1015 0000
 
 
 
f414 0000
 
 
 
0200 0301 -&gt; 0000 0001 0000 0011 0000 0000 0000 0010 -&gt; 32-bit data checksum
 
 
 
5834 6a88 2381
 
 
 
1354
 
 
 
0000 0000
 
 
 
475c 504e 3a44 6174 6150 524f 3b0d 0a47 5c54 413a ... 3736 3034 3833 3b0d 0a00 00be 979f a700
 
   
 
Data building issue: cf attached document from the customer.
 
   
 
Time packets issue: all time packets should be separated by the same value. However, sometimes, there is a difference:
 
 
 
Paquet Time 1 – 13h28m42s360ms
 
 
 
+190ms
 
 
 
Paquet Time 2 – 13h28m42s550ms
 
 
 
+190ms
 
 
 
Paquet Time 3 – 13h28m42s740ms
 
 
 
+190ms
 
 
 
Paquet Time 4 – 13h28m42s930ms
 
 
 
+200ms
 
 
 
Paquet Time 5 – 13h28m43s130ms
 
 
 
...
 
  
 Can you look at these please?
 Let me know if you have any question or need anything else from me/Dassault.
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 Data building issue.pdf
         
 
          
Maugan Robert (DTS)
 
Dec 5, 2022, 16:01 GMT+1
    Private note    
Dan - It definitely is from a build before since you haven't shared the latest one in which you solved the truncated data issue.
 Sorry for missing the files you sent on a previous answer. I've forwarded them to Dassault to see if they can figure out why the data does not appear in software like NetView.
  
 Stay tuned!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Nov 30, 2022, 22:46 GMT+1
    Private note    
Hi Maugan, is that from a build before?  I agree that one did not append sample data  if you look here:
  
 
  
 I posted a CH10 file where it should have samples included in the CH10 file?  the CH10Log file should contain a log of bytes as they are added to the file as a roadmap, so for example:
 
 and here are those same bytes in the file:
 
  
 I didn't create and send a build with these changes because the file wasn't validated by netview
 
 
         
 
          
Maugan Robert (DTS)
 
Nov 24, 2022, 09:47 GMT+1
    Private note    
Dan - the customer is reading the raw data with the linux command xxd and gets this:
  
 25eb ffff
 2800 0000
 0c00 0000
 0201 0311
 5834 6a88 2381
 423b
 3002 0000 to CSDW
 1114 0619 0711 2220 4827 2839 to 07/11/2022, 19h06min14s110ms
  
 25eb 0200
 2000 0000
 0400 0000
 0200 0309
 5834 6a88 2381
 3532
 0000 084f to CSDW
 0000 084f to DATA ?
  
 25eb 0300
 2000 0000
 0400 0000
 0200 0309
 5834 6a88 2381
 3632
 0000 084f to CSDW
 0000 084f to DATA ?
 ....
  
 After the CSDW, the file contains the same value again, instead of showing the data.
  
 Does it help?
  
 Thanks!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Nov 23, 2022, 20:23 GMT+1
    Private note    
Hi Maugan,
 I changed the code so that the PCM packets didn't get truncated, however in doing so netview no longer would read the file.  I don't currently have a way of identifying what the issue with the file is.  If Dassault is parsing the file themselves they might have an idea, but if they are using a library they may not be able to tell what the issue is either.  I did attach a .ch10 file on Nov 9th that has the pcm packets in it.  I was hoping to find some code that would read a ch10 file that I could use to identify the issue but all I found were executables and binaries.
 
 
         
 
          
Maugan Robert (DTS)
 
Nov 23, 2022, 10:08 GMT+1
    Private note    
Dan - any update on this topic since Nov 9th, please?
 
 
         
 
          
Dan McFadden (DTS)
 
Nov 9, 2022, 20:23 GMT+1
    Private note    
need to keep working on it, that export is not recognized as a valid file in NetView.  I'll try to simlify the PCM packet down till it passes.
 
 
         
 
          
Dan McFadden (DTS)
 
Nov 9, 2022, 19:55 GMT+1
    Private note    
the PCM packets were getting truncated.
  
 I'll post a new build in a little bit, here's what a list of bytes going into the packets as well as a dataset and an export that wasn't truncated.
  
 
 
 
Attachment(s)
 S6AStreamTest.7z
 CH10Log.txt
 2022_09_09 13_27_UNF.ch10
         
 
          
Dan McFadden (DTS)
 
Nov 9, 2022, 17:30 GMT+1
    Private note    
running with the data in EG_450_9_VV, it does appear to be working, but very slowly ... I notice there is 108,000,001 samples ...
  
 the CH10 export does a couple of things which cause all the samples to be loaded into memory or at least processed, for example;
  
                 var a = scaler.GetEU(aic.PersistentChannelInfo.MaxADC);
                 var b = scaler.GetEU(aic.PersistentChannelInfo.MinADC);
                 template = template.Replace("{CHANNEL MAX RANGE EU}", $"{Math.Max(a,b)}");
                 template = template.Replace("{CHANNEL MIN RANGE EU}", $"{Math.Min(a, b)}");
  
             internal void ComputeMinMaxADC()
             {
                 var min = short.MaxValue;
                 var max = short.MinValue;
                 for (ulong sample = 0; sample &lt; NumberOfSamples; sample++)
                 {
  
  
 and there's no feedback during this particular area where it's replacing the tokens in the TMATS template.
  
 I haven't finished the export yet, but I think the likely issue is the length of the recording.  I noticed the test was setup up for double that length as well, meaning they could have intended to have even double that data.
  
 For the purpose of the CH 10 export we might want to abandon our existing classes and structures for accessing data for something faster and more direct, but I'd want to talk to Chris Balogh before making any of those changes.
  
 I'll start working on the second part of the query - where's the data.  I think this is likely coming from the change in the packing structure from throughput to packed, or from the lack of the measurand list, but let me verify and see if I can help
 
 
         
 
          
Dan McFadden (DTS)
 
Nov 9, 2022, 01:16 GMT+1
    Private note    
Hi Maugan,
  
 I expect to check this out both these items tomorrow.
 
 
         
 
          
Maugan Robert (DTS)
 
Nov 8, 2022, 11:59 GMT+1
 
Hi Dan,
  
 Am I missing something here or is DataPRO NOT exporting any data in the ch10 file? I tried to record some data with a SLICE6 AIR and three channels (A64C/ARS/IEPE) plugged to the unit, but when I export the data in ch10 format with build 783, Dassault tells me that there is no data in the file (see attached) - I don't know how to verify that since everything below the header is not directly readable.
  
 Also, I tried to export their latest flight test recording Dassault made with the unit they received a few weeks ago, and DataPRO does nothing when I click on the Run button to export the data in chapter10 format.
 They have configured the SLICE6 AIR and downloaded the data out of it with DataPRO 3.3.609. Then I got the whole data folder and copied it in my C:\DTS\DTS.Suite\Data folder. I opened build 783 and tried to run the export in chapter10, but nothing happens and I can only close DataPRO.
  
 I have copied their data folder here: \\dts\files\!Temp!\Maugan\EG_450_9_VV\
  
 Could you please help me here?
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 2022_11_07 18_04_UNF.ch10
         
 
          
Dan McFadden (DTS)
 
Oct 28, 2022, 20:06 GMT+2
    Private note    
Hi Maugan,
 I've added PCM intrapacket headers into the chapter 10 export.  I set the mode to packed 16 bit.  I left the framesync as 0x90EB.  I haven't had luck validating the export.  The time does show accurately in netview, but it doesn't show any data for the PCM channel itself - maybe because of the missing measurand list.  The last request for the TMATs change cut the measurand list out.  Netview also shows the PCM channel as throughput even though the packed bit is set in the PCM packet and throughput bit is not set.
  
 DP 3.3.783 should have the change present. 
  
 https://dts.box.com/s/gnj9ghm3wh4d2hesk9f0tcmwto5524or
  
 I've also attached a 1 channel dataset and the resulting CH10 file from the export.
  
 with regards to time sync, the current data files expose two time sync datapoints, these can be seen for instance in the .dts file:
  
 
  
 in this particular case the DAS is not timesync'd.  The export uses the StartRecordTimeSec and StartRecordTimeStampNanoSec when available and then each intrapacket header is extrapolated based on the sample rate and the sample number.
  
 As far as the intrapacket headers, those will occur at the end of minor frames with the exception of the first one where data bits are after the Intra-packet time stamp, so the frequency of the headers are a factor of the sample rate and the frame size.  With the current framesize after the first packet there should be a header after every 127 samples.
  
 As always, happy to help, but I might need their help in adjusting the output to whatever they need.
  
  
 
 
 
Attachment(s)
 test2.7z
 2022_07_25 09_18_UNF.ch10
         
 
          
Maugan Robert (DTS)
 
Oct 28, 2022, 12:38 GMT+2
 
Sorry for the french, my head got messed up with a customer call when writing the ticket.
  
 "Voici les demandes/commentaires :" means "Here are the requests/comments:"
  
 Maugan
 
 
         
 
          
Maugan Robert (DTS)
 
Oct 28, 2022, 12:36 GMT+2
 
Good morning Dan,
  
 Sorry for the delayed answer, the customer email didn't leave his outbox and his colleague figured it out after seeing no response from me after a few days - which is unusual :)
  
 Voici les demandes/commentaires : 
 
Mode: they ask if we can implement the Data-Packed mode rather than the Unpacked mode as the Packed mode is the format used by most of the usual suppliers, including Zodiac with their MDR.
 
  
 
  
   
 
The FrameSync is 90eb, which is already 16bit, so what have you changed exactly when you say "I also changed the frame sync to 16 bit just to make it a little clear for myself"
 
   
 
Timestamp: they are all good with the RTC value. To be sure, they want us to confirm that this value accuracy is within 10th of microseconds. Is it correct?
 
  
 Thanks!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Oct 21, 2022, 23:35 GMT+2
    Private note    
Hi Maugan,
  
 I had some time to work on this today and started work on it.  A few questions for Dassault;
  
 We had been using PCM Throughput mode for the export, but this doesn't seem to support intrapacket headers
  
 
  
 the mode I selected when I started work was unpacked, which does support the intrapacket; time stamps
 
  
 to do this I also changed the frame sync to 16 bit just to make it a little clear for myself.
  
 Finally the timestamps themselves.  In the current export we are using the 48 bit RTC.  just double checking that's still ok
  
 
  
 I'll keep going expecting this is fine, let me know if they need a different structure or absolute time.
  
  
 
 
         
 
          
Dan McFadden (DTS)
 
Oct 20, 2022, 22:54 GMT+2
    Private note    
Hi Maugan,
  
 I still think it can be put in in the next two weeks, it's not that bad to implement I think but the work queue keeps getting things shoved onto the top of it.  I haven't forgotten it, I promise.
 
 
         
 
          
Maugan Robert (DTS)
 
Oct 19, 2022, 19:51 GMT+2
 
Dan - The customer has sent me a reminder, asking me for the lead time on this feature request.
 Could you please let me know how long you believe you need to complete this intra-packet timestamp header implementation?
  
 Thanks!
 Maugan
 
 
         
 
          
Maugan Robert (DTS)
 
Oct 13, 2022, 12:29 GMT+2
 
Hi Dan,
  
 Yep, you have found exactly the definition of the Intra-packet header :)
 Let me know if you need anything else from me.
  
 Thanks!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Oct 12, 2022, 20:45 GMT+2
    Private note    
I believe this is the section they are requesting for:
 
 
 
         
 
          
Dan McFadden (DTS)
 
Oct 12, 2022, 20:43 GMT+2
    Private note    
Strike that last request
 
 
         
 
          
Dan McFadden (DTS)
 
Oct 12, 2022, 20:28 GMT+2
    Private note    
Hi Maugan,
 I've been a bit busy lately and haven't had any significant progress on the intrapacket headers yet.  I did look into the CH 11 PDF on time packets to see if there was something I could use to start working with, I've noticed there's a couple of different time formats and structures.  The first thing I think I might suggest would be to add network time packets;
  
 
  
 but these aren't called intra packet time headers, there are other formats that include intra packet headers like
  
 c. MIL-STD-1553 Intra-Packet Header. After the channel-specific data, the MIL-STD-1553 data are inserted into the packet in messages. Each MIL-STD-1553 message is preceded by an IPH consisting of an IPTS and an IPDH.
  
 Can you query what they need for the additional time granularity they are looking for?  Are NTP packets sufficient or are they looking for a 1553 packet like:
  
 
  
 
 
         
 
          
Dan McFadden (DTS)
 
Oct 5, 2022, 01:21 GMT+2
    Private note    
Hi Maugan,
 I haven't started yet, but plan on starting this week.
 
 
         
 
          
Maugan Robert (DTS)
 
Oct 4, 2022, 15:15 GMT+2
 
Hi Dan,
  
 The customer is happy with the file you provided, thanks a lot for your work on this!
 Now they would like to know when they can expect the insertion of the Intra Packet timestamps to be done/completed. Have you started to work on this yet?
  
 Thanks!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 23, 2022, 23:59 GMT+2
    Private note    
Hi Maugan,
  
 I think I understood the request.  I modelled the targets after TMATS_target.PDF.  I have not committed any changes yet and I need to document the changes, but here is an export using the changes to the template.
  
 I also attached the dataset that produced the export just for reference, but it's the same dataset as previously posted.
  
 
 
 
Attachment(s)
 2022_09_09 13_27_UNF.ch10
 S6AStreamTest.7z
         
 
          
Maugan Robert (DTS)
 
Sep 22, 2022, 16:47 GMT+2
 
Hi Dan,
  
 I've attached two files: one is the extracted TMATS from the export, with comments, and the other one is what the customer is expecting/targeting (refer to the powerpoint attached to my previous post for more details).
  
 They seem to still struggle to link parameters to the proper channel and have all the channel parameters gathered in one paragraph instead of being dispatched at different locations of the TMATS part of the ch10 file.
  
 Could you please have a look and either provide answers or modifications to the export to understand/match what they want?
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 TMATS_commented extraction.pdf
 TMATS_target.pdf
         
 
          
Dan McFadden (DTS)
 
Sep 15, 2022, 19:47 GMT+2
    Private note    
sure, I streamed with a S6A, got the tmt of the stream, then collected a dataset and exported.  I'll attach the Stream tmt, as well as the dataset itself (which has the export in it).  I will also include the two template files that are used to build the TMATs part of the export
  
 
 
 
Attachment(s)
 S6AStreamTest.7z
 S6A0081_TMT.txt
 S6ATMTTemplate_PCM_ExportBase.tmt
 S6ATMTTemplate_PCM_ExportChannel.tmt
         
 
          
Maugan Robert (DTS)
 
Sep 15, 2022, 19:12 GMT+2
 
Does it? Do you have an example of .ch10 file? I couldn't verify it on my laptop.
  
 Thx!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 15, 2022, 16:56 GMT+2
    Private note    
good news, the new version does exactly that (one block r/p/d/c)
 
 
         
 
          
Maugan Robert (DTS)
 
Sep 15, 2022, 12:24 GMT+2
 
Hi Dan,
  
 Thanks a lot for working on this so quickly. Dassault really appreciates the fast support :)
  
 After further discussion/analysis on Dassault side, the team realized that the other DAS were exporting in ch10 a bit differently: the file contains all the parameters related to one channel in the same block (R/P/D/C/etc.), then comes the next channel parameters. Our ch10 export puts all the R parameters first, then all the P parameters, and then for each channel, all the D/C parameters.
 The customer is asking if we can export the same way others are exporting in ch10? I've attached their comparison ppt for reference.
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 TMATS_SLICE6_VS_ZODIAC.pptx
         
 
          
Dan McFadden (DTS)
 
Sep 15, 2022, 01:45 GMT+2
    Private note    
installer for DP 3.3.768 should include those 2 new template files;
  
 https://dts.box.com/s/vmc4lurrp3u1yamn46il4todw91ak0s5
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 14, 2022, 23:43 GMT+2
    Private note    
it occurs to me I may have to update the installer to copy those files as well, will upload a new version once I modify the installer
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 13, 2022, 00:04 GMT+2
    Private note    
Hi Maugan,
  
 Happy Monday!  I've uploaded an experimental version of DP 3.3.766 to
  
 https://dts.box.com/s/ohlj4gnzil70o2x01cqsnjmatpuxtr81
  
 with this build I made a lot of changes for CH10 export.
  
 It now exports to unfiltered
  
 it now uses template files to complete the TMATS portion of the file.  It adds to new template files to the TMTTemplates directory,  S6ATMTTemplate_PCM_ExportBase and S6ATMTTemplate_PCM_ExportChannel.  The ExportBase file is used to populate the common sections of the TMATS (test name, storage info), it borrows directly from S6ATMTTemplate_PCM, the template file used for streaming.  The Channels file is used to populate for information for channels in the test, this is also taken directly from the streaming template file.  I did this rather than using the streaming template as is because the streaming template is coded for a 6 channel S6A, and the CH10 export is not currently restricted to S6A, so there could be 18 channels or even considerably more.  Note that DTS test data could contain even different sample rates for different DAS in a test.  In order to support this in the CH10 export though I'll need to do some additional work.
  
 Additional when the DTS file contains start record timestamps (doesn't require a time sync'd s6A), it will use this information to set the first timestamp in the export.  It will use the fields from the DTS file: 
  
 StartRecordTimestampSec="1662755322" StartRecordTimestampNanoSec="362909960"
  
 it will treat this information as UNIX time information and then translate it to local time for the first time packet.
  
 I do not expect any missing properties in the TMATS file relative to the streaming template as the streaming template was directly used to create the TMATS packet in the export now, however some fields are now set using information that is in the streaming template like most significant bit direction which might not be consistent with how data is written in the export.
  
 netview did seem to accept the TMATS portion of the file, and showed the measurementlist was well, but I didn't see any PCM data to display.  I'll work with the export more to see if I missed something, but I'll probably switch to a few other projects first to make sure I don't fall behind for other items in the sprint.
 
 
         
 
          
Maugan Robert (DTS)
 
Sep 12, 2022, 10:15 GMT+2
 
Dan - thanks for the multiple answers and for all the work done here!
 Please keep me posted once you have a new build with all the features. Let me know if you have any question during the implementation.
  
 Happy Monday!
 Maugan
  
 ps: I know it was not "hardcoded" but rather generated, but you understood what I meant by using this word: not based on an external template/file that the user can edit :) 
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 9, 2022, 19:36 GMT+2
    Private note    
I'll also adjust MN-1-1 to channel name, like is used in the template file, and switch the measurement list name to Measurement List
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 9, 2022, 19:35 GMT+2
    Private note    
Measurementlists now added to export ch10 file: example;
 D-1\ML\N:1;
 D-1\MLN-1: EngineeringUnits;
 D-1\MN\N-1: 1;
 D-1\MN-1-1: g ;
 D-1\MN1-1-1: DE;
 D-1\MN2-1-1: D
 D-1\MN3-1-1: M
  
 for reference here's what the template file has:
 D-1\ML\N:1;
 D-1\MLN-1:Measurement List;
 D-1\COM: === Number of channels in the measurement list ===;
 D-1\MN\N-1:6;
 D-1\MN-1-1:{CHANNEL 1 NAME};
 D-1\MN1-1-1:DE;
 D-1\MN2-1-1:D;
 D-1\MN3-1-1:M;
  
 I may restructure the export to put all channels into one level rather than split into multiple levels as it does - the concern was that datasets in general can have multiple sample rates and even mutiple data periods and ROI, but perhaps it should just treat it simplified.
  
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 9, 2022, 19:29 GMT+2
    Private note    
2 - P-X\DLN is already in the export - here's an example of an output ch10 file with P-1\DLN: Channel 0001; no change needed for this one.
 
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 9, 2022, 17:39 GMT+2
    Private note    
1.2/1.3, I'm adding the section on measurandlists into the export;
  
 
 DLN was already in the export, but the measurement lists was not,.
  
 2.  Agree, P-X\DLN is in template file and not in export.  I don't see a description in 106-22 Chapter 9, May 2022, I will find it and add it.  I'll also go through the template file and see what other tags may not be present yet., thank you.
 3.  Agree, will do
 4.  Will do
 6.  Agree, will check the template and use that as to search for tags we may be missing and should have.
  
 As for timing, I've already added the Measurement list structure above into the code, so it can generate these tags now.  I've also already fixed the issue with MN2 and MN3 being swapped.  Hard coded is not the right word here as these are not hard coded, rather the output is being generated through code.  The intra packet header will need to wait for next sprint (2022-09-20) before I can probably start it as it's probably too much work to fit into the existing sprint, but with any luck I'll be able to add any of the other missing sections within the current sprint, so I will update the ticket next week with progress.
 
 
         
 
          
Maugan Robert (DTS)
 
Sep 9, 2022, 10:20 GMT+2
 
Dan McFadden - I forgot the main question: what is the timeline for each modification/added feature?
  
 Thx!
 Maugan
 
 
         
 
          
Maugan Robert (DTS)
 
Sep 9, 2022, 10:09 GMT+2
 
Hi Dan, Loc,
  
 Thanks for the answers.
  
 1.1: Thanks for adding it. It should be D-1\MN-1-X with X being the channel name (cf TMATS template in DataPRO folder). Though the channel name appears at multiple places, all these are mandatory to make sure each property type (C, D, P, etc) belongs to the proper channel
  
 1.2/1.3: Yes, you see these properties in the TMATS template for streaming. But I'm talking about the CH10 export, which is apparently NOT using the TMATS template but rather is completely hardcoded in DataPRO as it is missing lots of parameters that are included in the TMATS template. If you look at one of the CH10 exported files included in the data zipped files I sent in my previous post (TRIDEM1, 2 or 3), you will see that "C-X\DCN" never shows up in the .ch10 exported file for example. Same for "C-X\MN1":
  
 
  
 1.4: Thanks for figuring this typo out :) Indeed, should be easy to fix.
  
 2. Thanks for the answer. Same remark here: "P-X\DLN" appears in the TMATS template, but not in the exported ch10 file. So I guess it hasn't been coded to be generated during the export. Here is an example of a ch10 export:
  
 
  
 3. If the data is exported un/pre-filtered, could you please correct the export process to save the .ch10 file in a "UNFILTERED" folder instead of a "FILTERED" one? This will avoid confusion for customers.
  
 4. So you confirm that this is simply the time when the data is exported, right?
  
 5. Awesome, that should help them a lot! Please keep me posted on this ticket once it has been implemented.
  
 6. Thanks for the explanation/confirmation. But once again, there are missing properties in the exported .ch10 file which need to be included.
  
 I've put these answers in your Note file if it's easier for you ;)
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 29590.one
         
 
          
Dan McFadden (DTS)
 
Sep 8, 2022, 01:13 GMT+2
    Private note    
Agree we are talking about the same thing, I was wondering if they wanted something other than channel name since it already exists in like 3 places.
 
 
         
 
          
Loc Pham (DTS)
 
Sep 8, 2022, 01:09 GMT+2
    Private note    
I added response from Eric with more info (also CC'ed Eric to this ticket)
  
 " Required for data scaling in PCM stream format. For example (DataPRO PCM TMATS template):
  
 
  
  
  
  
  
 
 "
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 8, 2022, 00:01 GMT+2
    Private note    
upon further review I think 
 1.1 D-1\MN-1-X maybe refers to 
 MEASUREMENT NAME (D-x\MN-y-n) (9-58)
 which I do see in the spec, so I'll add it, is this still channel 1 name though?
 
 
         
 
          
Dan McFadden (DTS)
 
Sep 7, 2022, 01:39 GMT+2
    Private note    
Hi Maugan, I think these should answer the questions.  There are currently two items I'll create a work ticket to work on  (1.4 - C-X\MN3 is currently stored in C-X\MN2), and 5 (intra packet timestamp).  I could foresee they may also want changes for 4 (time of first packet).  Once I create the items I'll work on where they will be in the schedule.  1-4 is just a typo and can be fixed immediately, but the intra packet timestamp might require some additional code.  When I was working on the issue I was using one-note, so I included that as well in case it's easier to edit there and re-export.
  
  
 
 
 
Attachment(s)
 29590.pdf
 29590.one
         
 
          
Dan McFadden (DTS)
 
Sep 2, 2022, 17:50 GMT+2
    Private note    
Hi Maugan, I have a lot of items already in the queue to work on so I might not be able to look at the questions in a timely manner.  I've created an issue so that we can get to it in the next sprint (tuesday next week) and make sure it we make time to look at it.
  
 29590 Answer Dassault questions
 
 
         
 
          
Maugan Robert (DTS)
 
Sep 2, 2022, 16:53 GMT+2
 
Hi Dan, Chris,
  
 I had a meeting with Dassault today and they have several questions/requests. Please find them below.
   
 
In the exported ch10 file, the channel name/units aren't defined. They should be under the following settings but these don't appear in the exported file: 
 
D-1\MN-1-X:{CHANNEL X NAME}
 
C-1\DCN:{CHANNEL 1 NAME}
 
C-1\MN1:{CHANNEL 1 NAME}
 
C-1\MN3:{CHANNEL 1 EU}
 
 
 
Are the P-X and C-X parameters linked to each X channel? The customer has no way to match them with a specific channel other than making the assumption that all P-1 parameters are for channel 2 (channel 1 being the time), P-2 parameters are for channel 3, etc. Or are they independant from the channels? If they are correct, P-X\DLN should contain this info.
 
The data is exported in a "FILTERED" sub-folder when chosing the ch10 format, but is the data filtered with the software filters or is it the raw data just exported by default in a filtered folder?
 
When the SLICE6 AIR isn't sync'd with an external clock, what is the time in the first packet? See attached file "FirstPackets_TRIDEM1.txt": 09h27m59s610ms. I assume it's the export time of the PC, like in the CSV header, but I might be wrong. Could you confirm?
 
Timing of the packets: Dassault seems to have identified an issue =&gt; if they add 1/sampling rate to each data word time, then the time of the last word of the packet (# 7500) is superior to the time of the next packet. They believe it is due to the accuracy of the ch10 time definition which is within 10ms. They ask if we can add the "Intra Packet Timestamp" parameter in each minor frame which is more accurate than the general time packet and would allow the sync of data in time between each minor frame. Here is what they have found/measured depending on the sampling rate: 
 
For F=5kHz, the delay between the packets is 1500ms, but every 17 packets, it's 1490ms
 
For F=25kHz, the delay between the packets is 300ms, but every 17 packets, it's 290ms
 
For F=100kHz, the delay between the packets is 75ms, but every 17 packets, it's 70ms
 
 
 
  
 Also, I have an additional question: is the ch10 export using the TMATS template like when streaming data or are the TMATS parameters directly coded in the software? Because when you export data in ch10 format, you don't have all the same parameters as in the TMATS template in the software folder.
  
 Could you let me know if it's possible to modify the export function according to Dassault's request so they can sync the data in time properly?
  
 I have attached their documentation if it can help understand the issue, though it's in french, but Google can help you :)
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 FirstPackets_TRIDEM1.txt
 FirstPackets_TRIDEM2.txt
 FirstPackets_TRIDEM3.txt
 TRIDEM1.zip
 TRIDEM2.zip
 TRIDEM3.zip
 problemeDatationEchantillons.pdf
 problemeTMATS.pdf
 DatationPaquetsTime.pdf
         
 
          
Maugan Robert (DTS)
 
Aug 3, 2022, 08:51 GMT+2
 
Dan - thanks a lot for the detailed answer, it will definitely help the customer a lot!
 It may be useful to add the sampling rate in the SR setting, but nothing urgent I think.
  
 Please keep me posted on the two missing values when you find a way to have them available in the export somehow.
  
 Thanks!
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Aug 2, 2022, 20:35 GMT+2
 
 
1. I believe this is true, I did not verify.  If it's not we can correct it.
 
2.1. - we developed around September 2007 version of document, I'm not
 sure it had SR field available in data conversion attributes, I'd be
 happy to add it once I can get some details on it.  We do not currently
 use it.
 
2.2 currently D2 is being populated with:
 
pcm.BitsPerSecond = Convert.ToInt32(16 * channel.ParentModule.SampleRateHz)
 
So D2 currently contains bits per second rather than samples per second,
 dividing by 16 should be the sample rate for that channel, so agree D2
 of 400000 would correspond to 25k samples per second.
 
3.
 
PCM - Sample data 12 80 11 80 11 80
 
taking first two bytes (12 80)
 
0x8012 = 32786 [ushort], converting to signed short by subtracting
 -0x8000 = 0x0012
 
converting to decimal we have 18 ADC, which matches what we see in the
 viewer
 
ADC in DataPRO viewer
 
converting to EU depends on a couple of factors looking in the TMATS in
 a binary editor:
 
the scalefactor here appears to be correct (-0.0760637...) but the
 intercept/offset appears to be incorrect, it's listed as 0 in this example.
 
so I suspect as long as they are using a linear sensor and there's no
 excitation proportionality to consider their data should be scaled
 correctly, but with an unexpected offset present.
 
internally there's two additional variables that are being used to get to EU
 
(ADC - DataZeroLevelADC)*ScaleFactor + offset.  These parameters may
 depend on what values are used in the sensor settings for software
 zeroing and initial offset.
 
in the particular example I'm looking at the zero ADC is 20 and the user
 offset is also 20, so the equation would be more like (18-20)*-.076... +
 20 = ~ 20.15
 
EU in DP viewer
 
I'll see if those variables are being exposed elsewhere in the TMATs or
 if we can adjust C-1\C0 to reflect the proper offset...
 
 
Attachment(s)
 QUOLNANgLklT0EOt.png
 0AWCGKIWXTLO0jFv.png
 Unj0305OBJSmvuF4.png
 image704382.png
 image550465.png
 image681172.png
 image555867.png
         
 
          
Maugan Robert (DTS)
 
Aug 2, 2022, 08:22 GMT+2
 
Hi Dan, Loc,
  
 Thanks for the info.
  
 A couple more questions came in from the customer: 
 
Is the number of recorded channels equal to the number of PCMIN entries in the TMATS?
 
Sampling rate: 
 
In the Data Conversion Attributes Group of the TMATS, a "SR" field can be used for the sampling rate (cf attachment), but it is not present in the TMATS. So the sampling rate info should not be found here, correct?
 
In the PCM Format Attributes Group of the TMATS, a D2 field (BIT RATE) is used and contain a value. Is it the sampling rate that allows the customer to retrieve the timescale between each recorded sample? The "MF1" and "MF2" fields tell them that the setting is 16bits. D2 being 400000, how do they calc the sampling rate? 400000/16 = 25kHz?
 
 
 
Sample value: 
 
After 90eb, the first 16bits is 8001. Converted in decimal, it gives 32769.
 
From this value, how do they retrieve the value in mV or EU?
 
They suggested an AX+B formula with A=C-1\CO-1 and B=C-1\CO, but I doubt this is the proper way to do it.
 
 
 
  
 From the TMATS: 
 
P-1\TF:ONE; TYPE FORMAT
 
 
 
P-1\F1:16; COMMON WORD LENGTH
 
 
 
P-1\F2:M; WORD TRANSFER ORDER
 
 
 
P-1\F3:NO; PARITY
 
 
 
P-1\D1:NRZ-L; PCM CODE
 
 
 
P-1\D2:400000; BIT RATE
 
 
 
P-1\D4:N; POLARITY
 
 
 
P-1\D6:N; DATA DIRECTION
 
 
 
P-1\MF\N:1; NUMBER OF MINOR FRAMES IN MAJOR FRAME
 
 
 
P-1\MF1:500; NUMBER OF WORDS IN A MINOR FRAME
 
 
 
P-1\MF2:8000; NUMBER OF BITS IN A MINOR FRAME
 
 
 
P-1\MF4:16; LENGTH
 
 
 
P-1\MF5:1110101110010000; PATTERN à EB90
 
 
 
C-1\MN2:g ; EXCITATION VOLTAGE
 
 
 
C-1\BFM:UNS; BINARY FORMAT
 
 
 
C-1\DCT:COE; CONVERSION TYPE
 
 
 
C-1\CO\N:1; ORDER OF CURVE FIT
 
 
 
C-1\CO:0; COEFFICIENT (0)
 
 
 
C-1\CO-1:0.0231634452939034; N-TH COEFFICIENT
 
 
 
C-1\MOT1:0.5328; HIGH MEASUREMENT VALUE
 
 
 
C-1\MOT2:-0.4169; LOW MEASUREMENT VALUE
 
 
 
C-1\MOT3:0.5328; HIGH ALERT LIMIT VALUE
 
 
 
C-1\MOT4:-0.4169; LOW ALERT LIMIT VALUE
 
 
 
C-1\MOT5:0.5328; HIGH WARNING LIMIT VALUE
 
 
 
C-1\MOT6:-0.4169; LOW WARNING LIMIT VALUE
 
  
 Thanks!
 Maugan
 
 
 
Attachment(s)
 sampleRate.PNG
         
 
          
Dan McFadden (DTS)
 
Jul 29, 2022, 01:30 GMT+2
 
 
That's correct, it's UINT16/ushort ADC, 2 bytes.
 
here's the method we call when we are adding data to the packet;
 
        public void AddThroughputData(ushort[] data)
         {
             var newBuffer = new byte[_dataBytes.Length + data.Length *
 2 + FrameSync.Length];
             Buffer.BlockCopy(_dataBytes, 0, newBuffer, 0,
 _dataBytes.Length);
             Buffer.BlockCopy(FrameSync, 0, newBuffer,
 _dataBytes.Length, FrameSync.Length);
             Buffer.BlockCopy(data, 0, newBuffer, _dataBytes.Length +
 FrameSync.Length, data.Length * 2);
             _dataBytes = newBuffer;
         }
 
in this case _databytes is any existing bytes/frames in the PCM packet,
 and we start by enlarging the buffer, copying in the old buffer, then
 copying the framesync, then copying in all the ushort data.  The ushort
 data is not byte reversed for network order, they are just copied
 directly into the buffer.  Each frame is currently around 500 samples. 
 each sample should be 1/sample rate apart, so at say sample 500 time
 would be start time + (500/sps)seconds.
 
We don't have any consumers of this export yet, so we are free to adapt
 the export to their needs, if they are able to work with us.
 
 
Attachment(s)
 image109099.png
 image312008.png
 image895584.png
 image722604.png
         
 
          
Maugan Robert (DTS)
 
Jul 28, 2022, 18:56 GMT+2
 
Dan McFadden - The customer still has questions about how to process the data.
  
 They refer to the following from the Chapter10 July 15 standard:
 
  
 So they understand the channel specific data is "00 00 10 0F" and then the minor frame data always starts with the FrameSync 90 EB. But then, how do they process the data? How long is a data point? 2 bytes (16 bits)? How is each data point related to the timescale of the recording?
  
 Thanks!
 Maugan
 
 
         
 
          
Maugan Robert (DTS)
 
Jul 28, 2022, 16:18 GMT+2
 
Hi Dan,
  
 Thanks for the work. I've share your answer/files with the customer and asked them for the full dataset of the export they already provided.
 I'll keep you posted.
  
 Maugan
  
  
 
 
         
 
          
Dan McFadden (DTS)
 
Jul 27, 2022, 23:15 GMT+2
    Private note    
I've modified the code to also output a log of the bytes more or less as it's writing them.  This should help narrow down where the bytes in question are what they belong to.  Most likely they are bytes that belong to a PCM data packet.  I'll add a log from a run with a dataset I have, I'll also attach the export file.  If they are okay sharing a dataset I can run the code with their dataset and generate a log, if not I can generate a test build of DataPRO for them that will output the log file.
  
 looking at the byte sequence you pasted below
   
 
0000 100f CSDW
 
 
 
then "90eb 0280 0380 0380 0280 0480 0580 0180 ..." which they can't decode.
 
 
 
 
 
 this looks like FrameSync (0x90eb) and then maybe data
  
 for example from the log: 
  
 Finished Writing Time Packet
 PCM - ChannelSpecificData 00 00 10 0F
 PCM - FrameSync 90 EB
 PCM - Sample data 73 81 71 81
  
 when it's actually writing the full packet here's the byte sequence without notation:
  
 Writing DataBytes 00 00 10 0F 90 EB 73 81
  
 these data bytes are made up of analog data counts (uint16)
  
 what are they expecting to see after the CSDW [00 00 10 0f]?  It looks like the framesync and data is unexpected, maybe we can change to match whatever they are expecting?
  
  
  
 
 
 
Attachment(s)
 2022_07_21 16_18_FIL.ch10
 CH10.txt
         
 
          
Dan McFadden (DTS)
 
Jul 27, 2022, 18:25 GMT+2
    Private note    
and by that I mean working on getting the information they need to get the data
  
 
 
         
 
          
Dan McFadden (DTS)
 
Jul 27, 2022, 18:25 GMT+2
    Private note    
Maugan Robert  - no that's ok for now, we'll just start with getting the data.
 
 
         
 
          
Maugan Robert (DTS)
 
Jul 27, 2022, 18:23 GMT+2
 
Dan McFadden - No idea about the time accuracy. Do you want me to ask them about this?
  
 Chris Balogh - I believe 3.3.609 or 705. Not sure which version I gave them during the product evaluation a few weeks ago.
  
 Maugan
 
 
         
 
          
Chris Balogh (DTS)
 
Jul 27, 2022, 17:48 GMT+2
 
Maugan Robert ,
   
 
However, their software, which reads the chapter10 format, isn't able to decode the data (it works fine for the header but throws an error when reading the data from the file).
 
 What software are they using?
 
 
         
 
          
Dan McFadden (DTS)
 
Jul 27, 2022, 17:40 GMT+2
    Private note    
no worries, I almost always reply internally and then if I need publicly out of habit.
 Do you know what their [Dassault] needs are for time accuracy for the samples?  we have a timestamp for the start of the event from the S6A, but currently from then on the time packets are calculated using the sample number and the start time.  I think the first step is for me to put something together for them and you can translate it as needed and intermediate it.  I'll update when I have something, but it'll definitely be a few hours I think with other things to do as well.
 
 
         
 
          
Maugan Robert (DTS)
 
Jul 27, 2022, 17:33 GMT+2
 
Sorry, forgot to mark the ticket as internal, so everybody can post public replies.
  
 Dan McFadden - As mentionned, the header seems to work just fine with what they know, but something is missing or not as expected in the data part of the exported ch10 file.
 They definitely need this export format to be able to work with the SLICE6 AIR on their tests.
  
 I'm sure they would be happy to work with us to validate the export format. I can either be the in-between person or create an account for these guys here and a new public ticket with them, though I'm not sure how good they are with English language.
  
 Let me know if you need anything from me.
  
 Maugan
 
 
         
 
          
Dan McFadden (DTS)
 
Jul 27, 2022, 17:23 GMT+2
    Private note    
I never marked CH10 export complete as we had no way of ever testing it, and further the time synchronization in it was based on using the sample rate and the sample number, something that is available with every dataset, but not something that has a strict correlation to time synced data and S6A data - every time I put in a time packet it's just calculated, I believe we hid the option to export CH10 data in later versions of software for that reason.
  
 I'm happy to work with them and provide what the export currently outputs, I'm also interested in seeing if we can work with them for the CH10 export - finding a way to validate it was holding back completing the export.  Currently the chapter 10 export just takes a dataset that we have recorded in DTS binary form and constructs a CH10 file and fills it in based partially on what is in the CH10 documentation and partially based on how S6A is doing CH10 streaming.
  
 Probably the first step is for me to put together an example with what we are exporting and where the information is coming from
 
 
         
 
          
Mike Beckage (DTS)
 
Jul 27, 2022, 16:20 GMT+2
 
Chris - Hopefully an easy question?
 
 
         
 
          
Maugan Robert (DTS)
 
Jul 27, 2022, 15:40 GMT+2
 
Hi everybody,
  
 Dassault is working on the post-process of the SLICE6 AIR recorded data and they have exported a test in Chapter10 format. However, their software, which reads the chapter10 format, isn't able to decode the data (it works fine for the header but throws an error when reading the data from the file).
  
 See attached exported file. From this file, they recognize the following (example of ChannelID 2): 
 
//FIRST PACKET PCMIN 2
 
 
 
25eb 0200 SYNCHRO CHANNEL_ID
 
 
 
b83a 0000 PACKET LENGTH --&gt; 15032
 
 
 
9c3a 0000 DATA LENGTH --&gt; 15004
 
 
 
02 DATA TYPE VERSION
 
 
 
00 SEQUENCE NUMBER
 
 
 
03 PACKET FLAGS --&gt; 0000 0011 --&gt; 32-bit data checksum present
 
 
 
09 DATA TYPE
 
 
 
5834 6a88 2381 RTC
 
 
 
65a7 HEADER CHECKSUM
 
 
 
0000 100f CSDW
 
  
 But then they don't understand what follows: 90eb 0180 0180 ff7f 0380 0580 0180 0480 0380 0180 0380 0280 ...
 Same thing for the second packet: 
 
//SECOND PACKET PCMIN 2
 
 
 
25eb 0200
 
 
 
b83a 0000
 
 
 
9c3a 0000
 
 
 
02
 
 
 
01
 
 
 
03
 
 
 
09
 
 
 
a8e3 9788 2381
 
 
 
e257
 
 
 
0000 100f CSDW
 
 
 
then "90eb 0280 0380 0380 0280 0480 0580 0180 ..." which they can't decode.
 
  
 FYI, they make the assumption that the number of PCMIN ChannelID is identical to the number of channels recorded by the SLICE6.
  
 Could you please let me know the details of the chapter10 exported format from DataPRO? Which version is it (PCM/analog/etc.)? Any specific thing they should know about the data formating?
  
 Thanks!
 Maugan
  
 
 
 
Attachment(s)
 Run Test_32V_Run Test-Recovery1_FIL.7z
         
 
----------------------------------------------
 Customer Details:
 Name: Maugan Robert ( maugan.robert@dtsweb.com )
 Organization: DTS
 
----------------------------------------------
 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 # 10690   Status Open   Requester Maugan Robert   CCs Daniel Stelung, Maugan Robert, Mike Beckage   Followers Chris Balogh, Dan McFadden, Daniel Stelung, Eric Fizer, Kate Martin, Loc Pham, Maugan Robert, Mike Beckage   Group Support   Assignee Maugan Robert   Priority Normal   Type Problem   Channel Web Form    
 
 This email is a service from DTS. Delivered by Zendesk.
 
 [0KNRPL-YNR7K]Ticket-Id:10690Account-Subdomain:dtsweb</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2023-09-14T23:14:55Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>