Page 1 of 1

Handling of channel count > 999

Posted: Wed Oct 19, 2022 9:43 am
by DiVe
Dear colleagues,

since version 1.4 there is a extension available to handle more than 999 channels in the storage.
In RED A 1.4 you will find:
2022-10-18 13_11_04-ISO TS 13499 RED A V14 Paris_Hints - PDF-XChange Editor.png
2022-10-18 13_11_04-ISO TS 13499 RED A V14 Paris_Hints - PDF-XChange Editor.png (27.46 KiB) Viewed 2515 times
Variant A
We have interpreted "channel number" as "number of the channel" and not as "channel count" and so
in our implementation we do handle the numbering for channel numbers like:
<testname>.001
<testname>.002
...
<testname>.999
<testname>.1000
<testname>.1001
...

In the <testname>.chn file this will be reflected like:

Code: Select all

Name of channel 001         :10..
Name of channel 002         :10..
...
Name of channel 999         :B0..
Name of channel 1000        :B0..
Name of channel 1001        :B0..
...
Variant B
It seem that the statement from RED A can be interpreted as:
"Number all channels with a 4 digit file extension if there are more than 999 channel."
So here "channel number" is interpreted as "channel count".

Like:
<testname>.0001
<testname>.0002
...
<testname>.0999
<testname>.1000
<testname>.1001
...

How is this actually implemented and understood in other tools?

We should formulate the extension so that there is a unique understanding of how to implement this.
Best also with some demo lines like above in RED A.

Kind regards,
Dirk

Re: Handling of channel count > 999

Posted: Wed Oct 19, 2022 3:21 pm
by DiVe
Summary from the discussion 2022-10-19:

- We will verify the current implementation in the software tools used.
- The extension based on Variant A will only require to extend the read/write functions for channels >999.
All existing implemenations for channels < 1000 will be preserved.
- "channel number" is the number of a channel, otherwise "number of channels" has been used in the description of the extension in A.2.2.8
- Variant B requires the rewrite of all channels if the number of channels might be increased over the limit.
(e.g. calculated channels added to the channels)
...

Please add here more arguments for the two variants.
It will be also interesting if this extension is needed/in use at your customers or you own applications.

Re: Handling of channel count > 999

Posted: Wed Oct 19, 2022 3:45 pm
by DiVe
Feedback from Kistler for current implementation in CrashDesigner:
2022-10-19 17_44_36-Posteingang-dirk.vetter@iatmbh.com - Outlook.png
2022-10-19 17_44_36-Posteingang-dirk.vetter@iatmbh.com - Outlook.png (1.27 KiB) Viewed 2505 times

Re: Handling of channel count > 999

Posted: Fri Nov 04, 2022 12:32 pm
by MiBa
Handling in Messring's software

Dear colleagues,

Messring's software follows variant A only.
1. Measurement data with more than 999 channels following variant A is read-in correctly.
2. Measurement data with more than 999 channels is correctly written following variant A.
3. Measurement data following variant B is not read-in at all.
4. There is no possiblity to write measurement data following variant B.

If variant B should be supported we need further work.

Best regards
Michael

Re: Handling of channel count > 999

Posted: Tue Dec 20, 2022 10:14 am
by DiVe
Dear all,

as decided on the last task force meeting we will follow the approach of "Variant A" for the storage.
Indeed, most of the implementations are following this variant.

In the future we will destinkt the description of the implementation in RED A and add
an text example, like in this topic.

Kind regards,
Dirk

Re: Handling of channel count > 999

Posted: Mon Jan 16, 2023 1:25 pm
by DiVe
Dear all,
a verification run, supported by Walter Rick from National Instruments, proves,
that also the DIAdem load/save module for ISO MME supports the "Variant A".

Kind regrads,
Dirk