A numeric-looking CSV field is not an agreed number until the sender and receiver distinguish the decimal character, digit-grouping character and field delimiter. For a UG35 sensor-data inquiry, request an explicit export description and a small expected-value import test. Seeing a plausible number in a spreadsheet is not enough to prove that the recipient interpreted the delivered value correctly.

One token, more than one possible meaning

The text 1,234 can represent a grouped whole number under one agreed convention or a decimal value under another. In a comma-delimited file, an unquoted comma can also separate fields. These are different layers of interpretation. Before discussing sensor accuracy, the buyer needs to know which characters belong to the value and how the receiving application is instructed to interpret them.

This is a synthetic data-handover example, not a UG35 measurement or a reported customer incident. It does not claim that every application behaves the same way. The point is that a file extension and a visible column do not specify the complete import contract. A recipient should not have to guess the sender's numerical conventions from values that merely look familiar.

Separate three roles in the export description

The W3C CSV on the Web namespace vocabulary describes distinct properties for a decimal character, a grouping character and a field delimiter. These labels are useful for asking precise questions. The namespace document states that it has no official standing or consensus status; it is cited here as a vocabulary reference, not as a mandatory standard or a claim of UG35 software conformance.

Ask the sender to identify each role explicitly, including when grouping is not used. Then identify the receiver's actual parser or import workflow. A verbal agreement that the file is English is not an adequate replacement: language, display preferences and parsing rules are not the same thing. The documentation should be specific enough for a second recipient to reproduce the intended values without consulting the original sender.

Use a tiny fixture before a large dataset

Our editorial recommendation is to exchange a synthetic fixture before the first production handover. A fixture is a small test file with known expected results. It should contain only invented, nonsensitive values and should be labeled accordingly. The sender provides both the bytes to import and a separate expected-value table. The receiver runs the proposed workflow and compares its parsed output with that table.

For one deliberately simple convention, the parties might agree a period decimal character, no digit grouping and a semicolon field delimiter. Test values could include 0, 0.25, -0.25 and 1234.5. These are not suggested sensor readings or product specifications. They are examples chosen to make zero, fraction, sign and magnitude visible in the test. The actual delivery convention remains a project decision.

Add an explicitly permitted missing-value example and a deliberately invalid example if the workflow needs them. Specify the expected action for each, such as preserving a missing state or reporting a parsing error. Do not assume that an empty field should become zero, or that an unrecognized token should be silently repaired. Acceptance should cover the failure behavior as well as the successful conversion.

Check the parsed value, not only the display

A receiving application may display a value differently from its stored representation. Ask the receiver how it will inspect the actual parsed value and field type. A column that looks numeric may still be treated as text in a later step, while formatting can make two different representations look similar. The test should connect the delivered token to the intended numerical meaning.

Keep the scope practical. The buyer does not need to demand every possible locale combination. Name the actual receiving workflows and test those. If a second team uses a different application, add that workflow explicitly rather than assuming the first result covers it. Record any conversion step between recipients, including who owns it and how its output is checked.

Do not replace punctuation blindly

A quick global replacement of commas with periods can change field boundaries, text descriptions or other content that was not a decimal value. Treat correction as a defined transformation with a preserved input and a testable output. Ask why the original file did not match the agreed convention and whether the exporter can provide the correct format directly. A manual workaround should not become an undocumented production dependency.

If a conversion is necessary, retain its settings and identify which fields it is intended to affect. Run the fixture through the same transformation. The receiver should be able to distinguish a corrected export from a changed measurement. This recommendation does not prescribe a particular programming language or parser; it asks for a process that can be explained and checked in the actual receiving environment.

Keep units and missing states separate

Correctly parsing the number does not establish its unit, quantity or measurement context. Define those separately in the handover description. A value that changes magnitude during import is a parsing problem; a value used with the wrong unit is a different problem. Solving one should not be reported as solving both. The receiving team needs enough context to know what the number represents.

Also preserve the difference between a measured zero and an unavailable value. Decide how each appears in the export and how the receiver retains that distinction. This is a recommendation for the import contract, not an assertion about any particular sensor's output. Include the agreed cases in the fixture so that the distinction remains visible when the delivery workflow changes.

Make changes a reason to rerun the test

A successful fixture should be associated with the exporter, relevant configuration, receiver and import procedure that were actually tested. When one of those changes, identify whether the change can affect interpretation and rerun the relevant cases. Do not call every update a failure, but do not assume that a previous screenshot proves the new path behaves identically.

Keep a short acceptance record containing the test-file revision, expected results, observed results and any exceptions. Preserve the original delivered file. If a later disagreement arises, the parties can inspect the same input rather than comparing screenshots from differently edited copies. This record is a handover aid, not proof of the sensor's calibration, accuracy or suitability for the application.

Data files are only one part of the evidence package

An inspection delivery may include photographs and linked asset records as well as numerical fields. A successful numerical import does not prove that those relationships survived. The UG32 guide to GIS attachments describes a separate receiving-system trial for media and their parent records. Keep both tests visible when both are part of the contracted output.

Similarly, a calibration document may describe the instrument before or after adjustment, and the distinction matters independently of the file's numerical syntax. See the UG82 guide to as-found and as-left evidence when service records support a payload discussion. A correctly imported value still needs the right identity, time context and evidence before it supports a technical conclusion.

Frame the UG35 request around confirmed configuration

The UG35 product listing identifies the aircraft for the inquiry. It does not establish an included sensor, CSV export function, data logger or receiving-software integration. Ask which proposed component produces the data and who is responsible for the export description. For specifications, interfaces or service inclusions that are not confirmed, contact us for configuration details.

A buyer in the United States or Ireland should state the actual receiving workflow rather than infer it from the project's location. This guide does not claim a national convention for every organization, nor does it provide flight or regulatory advice. The useful procurement input is the recipient's documented requirement, tested against the proposed data path and separated from unverified aircraft or payload capabilities.

Questions for the import review

Does the CSV extension settle the number format?

No. Request the relevant syntax and numerical conventions, then test them in the intended receiver. A filename does not substitute for the expected-value table or establish how a specific application will parse the file.

Is opening the file without an error enough?

No. The acceptance test should compare field counts, parsed values and agreed missing states with the expected results. A successful open operation does not establish that every number has the intended meaning.

Should every recipient use identical display formatting?

Only if the project requires it. The more important question is whether the agreed numerical meaning survives the workflow. Distinguish a display preference from a parsing rule and record any required presentation convention separately.

Send a fixture with the payload brief

While reviewing the VTOL and fixed-wing drone collection, prepare a small synthetic input file, an expected-value table and the receiving application details. Add the intended quantities and units, the missing-value rule and any conversion step. These materials turn a vague request for compatible data into a concrete discussion of the proposed handover.

Submit the fixture through the UNITED UAV payload inquiry channel with your UG35 questions. Ask the supplier to identify the component and workflow responsible for producing the export, and request confirmation of what is included. The desired outcome is an agreed test of numerical meaning before production delivery, not a promise that any file carrying a CSV extension will work everywhere.