Questions and Answers.pdf

Questions and Answers

Question 1:

What kind of input signals are supplied to the system? Are both clock and data signals provided, and are the signals digital and reasonably free of noise? If digital signals are being provided, what signal levels can be expected – TTL, RS422, LVDS? This question tries to establish whether bits can be reliably captured digitally, potentially with clock recovery in the case of data-only signals, at the clock transitions, or whether some filtering or signal processing is required. Note that SoW item 2.1.8 appears to mention bit sync-related parameters, but otherwise the SoW does not explicitly call out bit sync capability as a requirement. Absent an explicit requirement, we need information about the signals in order to assess this.

Answer 1:

The input to the FEP is a digital PCM signal coming out of a TMoIP to PCM converter over approximately 3 feet of cable. The signal should be fairly free of noise. Both Data and Clock are present. The signal is TTL. Very minimal, if any at all, filtering or digital signal processing should be required.

Question 2:

SoW item 2.1.1 includes a requirement description for “32 Channels of Telemetry data, and, SoW item

2.1.2 includes a requirement description for “32 Channels of PCM data. Are those two requirement descriptions describing the same signal type?

Answer 2:

Section 2.1.1 is describing the total number of telemetry channels we need to process. Section 2.1.2 indicates one type of data we need to be able to process and Section 2.1.3 indicates a second type of data that we need to be able to process.

Question 3:

SoW item 2.1.7 includes a requirement description for three different operational modes, in-lock-weighted, last-in-lock, and data merging. May we have an expanded description of the operational expectations of these three modes? Which testing methodology will be used to demonstrate pass/fail compliance with this requirement?

Answer 3:

We understand that different companies use different algorithms to get the best data. This requirement is supposed to indicate that we would like some ability to determine how the system picks the best data and is not necessarily a requirement for a company to name their algorithms respectively. In general, we think “in-lock-weighted” indicates a data stream that is most often in-lock, “last-in-lock” would be a data stream that has most recently locked, and a “data merge” is an algorithm that attempts to create a unique best source stream that is not necessarily any of the incoming sources particularly but relies on selections from all the sources.

Again, we are not trying to dictate names for algorithms or how they should work, but we would like some control over how the best data output is configured so that we can adjust to different scenarios.

Question 4:

The introduction describes the current ITIPS systems as having the capability to monitor and analyse over 2,500 parameters, however, the requirements section (2.0) does not describe decommutation of parameters as a requirement. Is a decommutation capability a requirement for the new system, and if so, what parameter analysis is required?

Answer 4:

No decommutation is required at the Front-End Processor. ITIPS is more than just the FEP we are replacing. The best source output of the FEP will be sent to a decommutator for further analysis.

Question 5:

BDE supports in-lock-weighted, last-in-lock, data merging (bit vote), Ques�on: Define “last-in-lock" and how it is different than in-lock weighted?

Answer 5:

We understand that different companies use different algorithms to get the best data. This requirement is supposed to indicate that we would like some ability to determine how the system picks the best data and is not necessarily a requirement for a company to name their algorithms respectively. In general, we think “in-lock-weighted” indicates a data stream that is most often in-lock, “last-in-lock” would be a data stream that has most recently locked, and a “data merge” is an algorithm that attempts to create a unique best source stream that is not necessarily any of the incoming sources particularly but relies on selections from all of the sources. Again, we are not trying to dictate names for algorithms or how they should work, but we would like some control over how the best data output is configured so that we can adjust to different scenarios.

Ques�on 6:

Does this mean using any combina�on of PCM and TMoIP channels as an input for best source selec�on? If not, please define merging PCM channels with TMoIP channels.

Answer 6:

Yes, we would like the use any combination of TMoIP and PCM channels as inputs into the best source process.

Ques�on 7:

What is the source of data for the output stream? Is it a mirror of one of the input channels? Is it one of the best sources of output channel? Is it comprised of parameter data? Is it something else?

Answer 7:

The source data would be either a mirror of the input streams, or any of the created best source streams.

Ques�on 8:

Contractor sees these two requirements as an indica�on that bit synchroniza�on is required for each PCM input stream, also implying these may be serial PCM data-only only inputs.

Please confirm bit syncs are indeed required for the PCM input streams as Contractor does not see any specific bit sync opera�onal, or performance capabili�es, detailed in the requirements.

Answer 8:

This was modified to hopefully remove bit sync requirements.

Ques�on 9:

Sec�on 2.5 covers “warranty”, which applies to hardware. So in sec�on 2.4, is “technical support” the same as “so�ware product support”? If not, then please clarify what is meant by “technical support”?

Answer 9:

Every vendor uses different terminology, but we think “software product support” would equal “technical support”.

Ques�on 10:

Can you confirm that GPS: IRIG �me code conversion capability is not a requirement for the 32-channel systems?

Answer 10:

This looks like an oversight in our solicitation and it will need to be added to serve as a replacement.

Ques�on 11:

Is there a site demo test plan and is it available for review prior to visit? Can you provide a more detailed descrip�on of the test environment?

Answer 11:

The test plan/procedure is in work. A basic overview would be Wideband DRS8500 -> IMUX G2 -> Data Diode -> Computer running Omega NExT 3.0.0

Ques�on 12:

During the site evalua�on test will live or recorder file with PCM and Ethernet data be connected to the system? If so, what is the source of the data?

Answer 12:

A PCM recording played from a Wideband 8500 will be used for PCM data, and a IMUX G2 will be used for UDP CH10 data.

Ques�on 13:

Is there sample data available, to use for early tes�ng, and a descrip�on of the data, frame geometry, Bitrates, content within the data, etc.?

Answer 13:

Sample data used for testing is begin created, but four streams will be needed: Stream 1: 819.2kbps, 8192 bits/minor, no majors, F5CD00 sync. Stream 2: 1.6384Mbps, 8192 bits/minor, 2 major/minor.

Stream 3: 500kbps, 1152 bits/minor, 8 minors/major, FAF320 sync. Stream 4: 1.6Mbps, 1600 bits/minor, 20 minors/major, FAF320 sync.

Ques�on 14:

Do not see physical data replay requirement, so is one needed? Is it Single channel replay or mul�ple channel output replay?

Answer 14:

The front end processor will not need to replay PCM data.