A raw sensor word is not yet a signed measurement. Before accepting a proposed UG35 payload data interface, ask how the sender encodes a bipolar value and how the receiving application decodes it. Offset binary and two's complement can use the same number of bits and carry the same range of integer counts while assigning very different meanings to a particular word. Agree the coding, the width of the meaningful field and a few labeled examples before discussing conversion to engineering units. This is a data handover question, not a claim about electronics installed in the aircraft.

A zero that looks like the most negative value

Work through a four-bit example on paper. In an illustrative offset binary representation, the unsigned values zero through fifteen are displaced by eight to give signed counts from minus eight through plus seven. The raw word 1000 is therefore zero counts. In four-bit two's complement the same word represents minus eight counts. There is no missing byte and no ambiguity about which four digits were received. The disagreement is entirely about what the four digits mean.

Try a second word. The pattern 0000 is minus eight in the offset representation and zero in two's complement. The pattern 1111 is plus seven in the former and minus one in the latter. A receiver that chooses the wrong interpretation still produces integers in a plausible range. A broad minimum and maximum check might pass. An operator who looks at a chart without independently labelled input conditions might attribute the jump to the measured environment rather than a decoding error.

These numbers are teaching examples, not an input specification, a safe signal level or a calibration procedure. Real interfaces may reserve codes, insert status bits, change justification or report a value already converted by a digital controller. A bipolar physical quantity is not proof that the transmitted data uses either example exactly as shown. Ask for the interface document and the applied configuration for the output you will actually receive.

Why bit depth and polarity are insufficient

A proposal that says sixteen-bit bipolar output has answered two interesting questions but left a third open. Bit width describes the size of a field. Bipolar describes a quantity or range that can span positive and negative values. The coding maps specific bit patterns to signed counts. Two bidders may use the same words for the first two characteristics yet deliver files that require different interpretation. Treat output format as an interface requirement rather than a minor annotation to a sensor specification.

The Analog Devices Data Conversion Handbook, chapter two compares bipolar coding conventions. For corresponding offset binary and two's complement representations, complementing the most significant bit converts between the bit patterns. That relationship is about a correctly identified field of the stated width. It is not a reason to flip the high bit of an arbitrary packet, a floating-point value or a sample that the device driver has already converted.

Imagine a twelve-bit sample carried inside a larger storage word. Before identifying the significant bit that carries this distinction, the receiver must know which twelve bits belong to the value. Extra bits may be padding or carry unrelated information. Byte order tells the parser how to assemble bytes; it does not decide whether the assembled value is signed in the required coding. Keep the steps separate on the review sheet. A reviewer should be able to say whether a discrepancy appeared during extraction, interpretation or scaling.

Trace the word from the supplier file to the decision

Start at the point where responsibility transfers. Is the supplier handing over converter output, a framed stream from an acquisition unit, a driver-produced integer array or a spreadsheet of final values? The device manual may describe the first of these while the buyer actually receives the last. Ask the supplier to label each transformation up to the boundary. A statement about converter coding is useful evidence only if the proposed handover still carries that coding.

Next trace one value through the recipient's normal import path. Preserve the original bytes in a read-only example, identify the relevant field and write the decoded count beside the expected count. Apply the scale and offset only after those counts match. This order gives the reviewer a clean stopping point: if the count is already wrong, changing a calibration coefficient is not a valid remedy. It can make one point agree while leaving the rest of the range misinterpreted.

Do not demand a live energized demonstration when an approved recorded fixture can answer the question. A small set of labelled words generated for interface testing can isolate the decoder from wiring, analogue noise and changes in the environment. It must be identified as synthetic and must not be passed off as calibration evidence. If the project later needs verification of the physical measurement chain, that is a separate activity to be designed and authorized by qualified personnel.

Ask for examples on both sides of zero

A useful supplier packet contains the coding convention, effective word width, packing description, byte ordering where relevant, unit conversion and a designation of any invalid codes. Ask for at least one known negative count, a zero count and a positive count. Include one word close to a boundary where a sign mistake is easy to see. The expected result should come from the interface owner, not from the receiver whose implementation is being tested. Otherwise two copies of the same mistaken assumption may agree.

For each example record the raw representation exactly as delivered, including leading zeros. A value printed as a decimal number can hide the fact that a wider container was used or that a conversion already took place. Identify the field by name and version, then let the recipient reproduce the result without an undocumented spreadsheet formula. When a file is regenerated, retain the old fixture and its expected answers. A later interface revision can be compared without silently changing the basis for approval.

An effective review asks the recipient to predict the result before showing the supplier's report. If the prediction and report differ, investigate the field boundary, signed representation and scaling in that order. Do not choose the interpretation that produces the most attractive plot. It is possible to get a smooth curve over a narrow test range with the wrong decoder. A deliberately chosen pattern that changes interpretation at zero can be more informative than thousands of unlabeled field samples.

Keep acceptance of the decoder separate from calibration

Passing these examples establishes that a particular receiver interpreted a particular set of digital records as intended. It does not establish sensor accuracy, stability, allowable operating conditions or suitability for installation. It does not show that the sensor and aircraft share a compatible electrical interface. The useful purchasing outcome is smaller: one previously ambiguous part of the data chain now has a reproducible acceptance criterion.

For a simple handover, a short fixture file with expected outputs and an identifiable decoder revision may be sufficient. A programme with multiple receivers or changing suppliers may also require a versioned interface description and regression results for every receiving application. The second approach costs more to maintain. It earns its place when the same records will be interpreted by separate teams or when old measurements must remain readable after a software change.

A recurring receiving mistake is to keep only the final chart. When two tools later disagree, the chart cannot reveal whether the sender delivered different words or the readers assigned different meanings to identical ones. Keep the smallest lawful, non-sensitive raw excerpt that can settle that question. Store it with its expected decoded counts and the revision that defines them. That practical habit preserves an independent check without requiring the team to archive an entire mission for every software change.

Turn the distinction into an actionable UG35 inquiry

The UG35 mission payload platform listing identifies the aircraft under consideration, not an installed converter, protocol, power supply or approved sensor combination. Describe the proposed payload separately. Ask who supplies the acquisition hardware, who defines the field encoding and who maintains the receiving software. For installation limits or other configuration-specific facts not established in the offer, contact us for configuration details. Do not treat a correct offline decode as an aircraft integration release.

For a staged procurement, identify whether the coding fixture is evidence for the first item only or part of every software delivery. The first article approval guide addresses that boundary. If the measurements feed a terrain workflow, the contour level origin review describes a second, independent convention at the receiving end. Interpreting a digital zero correctly does not establish the vertical reference or the sequence of elevations in the finished map.

When comparing the VTOL and fixed-wing platforms, keep the airframe quotation distinct from the payload data work. Send an integration inquiry with the proposed interface revision, a non-sensitive packet example and the receiving system's expected count for each field. A supplier can then identify what is already documented, what must be demonstrated, and which part belongs to a third-party sensor provider. A labeled zero is a modest deliverable, but it makes an expensive disagreement much easier to diagnose.