A requested sampling rate is not sufficient evidence of the rate an acquisition system actually used. For a UG35 payload inquiry, ask the proposed equipment supplier to record both the requested value and the rate accepted by the configured hardware and software. Review how that information reaches the receiving analyst. This is an acquisition-package question, not a claim that UG35 includes a particular sensor, recorder or timing capability.

The value entered is only half the configuration story

A quotation can describe a data-acquisition requirement with an impressively precise number. The buyer sees that number repeated in a setup sheet and assumes the recording used it. Yet the sheet may show only what someone requested. If the acquisition system accepted a different supported value, the receiving analyst needs to know that before interpreting the data. The important distinction is between an intended setting and evidence of the accepted configuration.

That distinction is easy to miss when procurement, integration and analysis are handled by different people. The purchasing team asks for a capability, the integrator enters a setting and the analyst receives a file. Each person may believe the next handover carries enough context. A short configuration record can close that gap, provided it reports the actual system response rather than copying the original request into another template.

Why a requested rate can be adjusted

NI's Engineer's Guide to the Digitization of Analog Signals, on page 23, explains how a hardware timebase and divider can constrain available sample rates. A requested value may therefore be coerced to a supported value. The guide also treats timebase accuracy as a separate consideration. This is a generic explanation of acquisition hardware, not a specification for UG35.

The procurement consequence is modest but important: ask what the proposed system actually reports after configuration. Do not assume that every device rounds in the same direction or uses the same timing architecture. Do not transfer a numerical example from a technical guide to an aircraft quotation. The exact equipment, clock source, driver and configuration determine which evidence the supplier should provide for the proposed package.

Ask for a response record, not a screenshot of an input box

A screenshot showing a typed value can establish what the operator intended to request. It does not necessarily show what the system accepted. Ask the supplier to distinguish those two fields in the proposed evidence. The format can be simple: equipment identity, software identity, requested rate, reported rate and the date or version of the configuration being reviewed. The point is clarity, not a particular logging application.

Ask who produces that record and how it remains associated with the relevant data file. A perfectly clear configuration sheet is less useful if the analyst cannot determine which recording it describes. Conversely, a file name that resembles a configuration label is not enough unless the relationship is documented. The buyer should request an association that the receiving team can follow without reconstructing the sequence from informal messages.

A hypothetical handover review

Consider a buyer who commissions a sample recording to evaluate an optional measurement package. The setup request specifies a target rate, but the returned configuration record identifies a different accepted value. The supplier explains the difference using the documentation for the proposed equipment. The analyst can now decide whether that configuration meets the intended requirement. Without the returned value, the same analyst might unknowingly assess the file against an assumption.

The buyer should not automatically treat the difference as a failure. The original requirement may allow a range, or it may require a specific relationship that needs further review. Equally, the buyer should not accept the difference simply because the system produced data. Ask the responsible specialist to evaluate the requirement against the documented configuration and record the decision. That is more defensible than declaring every adjustment either harmless or unacceptable.

Keep this example hypothetical. It is not a report of a UG35 test, a customer incident or a measured performance result. No sample-rate number is proposed here. The example illustrates a procurement handover problem: the recipient must know what was configured before deciding whether the resulting evidence can support the intended analysis. The actual acceptance decision belongs to the qualified reviewers of the proposed measurement system.

Keep related timing questions separate

The accepted rate is one part of a timing description, not a substitute for every other question. Ask the supplier to identify which requirements the returned value addresses and which remain open. A statement about the rate should not silently become a statement about synchronization, event timing or the accuracy of a timestamp. Those may require different evidence, and this article does not establish that the proposed package provides it.

This separation helps prevent procurement shortcuts. A buyer may ask for one familiar number because it seems easy to compare between quotations. The better comparison is whether each proposal explains the relevant timing requirements and supplies evidence for them. Avoid awarding confidence to a precise-looking value while leaving its meaning unclear. Precision in a spreadsheet is not the same as a documented capability of the configured system.

Define the minimum configuration evidence

• The exact acquisition hardware and relevant software version.
• The sampling requirement and the value submitted during setup.
• The rate reported after configuration, with units and context.
• The clock or timing arrangement identified by the supplier.
• The recording or sample to which the configuration applies.
• The reviewer responsible for accepting any difference.

Use these items as a discussion outline rather than as a complete engineering specification. A qualified supplier may identify additional dependencies or explain that a different form of evidence is appropriate. Record those explanations in the proposal. The buyer should be able to distinguish a supported configuration from an unresolved request without pretending that a generic checklist can validate an unfamiliar instrument or an aircraft integration.

Ask the supplier to state whether the evidence is supplied only during an initial demonstration or accompanies later deliveries as well. A one-time sample can be useful for evaluating the proposed workflow, but it does not automatically describe every later configuration. If settings or components change, the buyer needs an agreed way to identify the affected deliverables and decide whether a new review is necessary.

Do not repair the record by relabeling it

If the accepted rate is unknown, changing a description to match the original request does not resolve the uncertainty. The editorial lesson is to preserve the distinction between a known system response and an assumed value. Ask for the available configuration evidence, document what remains missing and decide whether the file can be used within those limits. Do not manufacture a precise answer from a convenient label.

Similarly, this article does not recommend editing recorded timing information, modifying a controller or changing acquisition settings on an operational system. Those actions require the appropriate technical process and authorization. The buyer's task here is to ask for a truthful, traceable account of the proposed measurement configuration. A missing evidence item should lead to an explicit review question, not an improvised technical intervention.

Review the receiving workflow as well as the supplier response

Ask the intended analyst to demonstrate how the supplied configuration record will be found and interpreted. A handover is incomplete if the supplier provides a useful field that the recipient's workflow ignores. The review can be a short discussion around a representative file: where is the accepted rate recorded, who reads it and how is a discrepancy escalated? No special software purchase follows automatically from those questions.

Also identify the person who can approve a revised requirement. An analyst may understand the technical consequence of a difference without having authority to change the contract. A buyer may approve a commercial variation without understanding the measurement implications. A clear acceptance record should connect those responsibilities, keeping the technical assessment and contractual decision visible rather than assuming one substitutes for the other.

Use UG35 as the product reference, not a generic capability claim

The UG35 product listing identifies the aircraft for a configuration inquiry. Describe any requested sensor and acquisition package separately, including the decision the measurements must support. Do not assume an installed NI device, a particular interface, a clock architecture or an included analysis service. Ask the supplier to identify the proposed components and the evidence needed before making a compatibility or performance claim.

The discussion is intended for English-language procurement teams in the United States and Australia. It does not establish local operating approval, a mandatory test method or market demand. Aircraft operation and integration require their own project-specific review. The limited issue here is whether the proposed acquisition handover distinguishes the rate that was requested from the rate the configured system actually reports.

Questions buyers often leave unanswered

Is a reported accepted rate a calibration certificate?

No. It is configuration evidence. Ask the supplier what separate evidence addresses accuracy or other measurement requirements. A record of what the system accepted should not be presented as proof of every performance claim attached to the resulting data.

Can the request and returned value be the same?

They may be, but the buyer should establish that from the proposed system's evidence rather than from assumption. The value of the review is the documented relationship, including any relevant limitation, not a requirement that a discrepancy must exist.

Request the paired values before comparing quotations

Source note: the NI guide was checked on 21 October 2026; no publication date was established. Its generic timing explanation does not certify UG35 equipment. Related buyer checks include explaining pauses in a thermal recording and documenting transformations applied before a statistical summary.

Review the VTOL and fixed-wing collection and contact UNITED UAV with your measurement objective, proposed component references and required evidence. Ask for a UG35 configuration discussion that keeps aircraft supply and optional acquisition work separate. Request both the submitted rate and the accepted-rate record, together with the reviewer who will decide whether they satisfy the actual requirement.