The metadata RF teams wish they had six months later

Metadata feels different later

Metadata rarely feels urgent during collection.

The urgent work is getting the capture. The receiver is configured. The test window is short. The range schedule is tight. The disk is filling. The team wants the data saved, moved, and backed up before anything changes.

That is understandable. In the moment, metadata can feel like paperwork around the real work.

Six months later, it feels different.

Someone asks for the capture from a test event. They remember the signal roughly. Maybe the center frequency. Maybe the sensor. Maybe the week it happened. Maybe the fact that one run had the useful anomaly and three other runs did not.

Now the team has to reconstruct the context.

Which file was it? Was this the raw capture or a processed copy? What sample rate was used? Was the gain changed between runs? Which antenna or sensor collected it? Was the file from the lab, the range, or a field system? Did anyone already create a spectrogram, notebook, detection output, or filtered segment from it?

The capture may still exist. The hard part is knowing what it is.

The six-month-later problem

RF teams usually do not lose data in one dramatic failure. They lose usability slowly.

A capture lands on a shared drive. Someone adds a filename that made sense that day. Another person copies it into a project folder. A spreadsheet tracks a few fields. A script extracts something else. An analyst writes notes in a notebook. A derived file gets saved next to a report. Later, an object key or folder name becomes the only clue anyone can find quickly.

A large IQ capture is not self-explanatory. Opening it may require the right tool, enough local disk, and enough time to move the file. The team still needs to know how the data was collected and what happened after collection.

Without that context, old captures become expensive to trust.

Metadata engineers actually search for

The useful metadata is the set of details an engineer wishes were attached when someone asks about the data later.

At minimum, most RF teams want fields like center frequency, sample rate, bandwidth, timestamp and duration, sensor or source system, collection location or test range, antenna, gain, front-end configuration, file format, capture type, collection event, operator or automated source, environment notes, and links to derived outputs.

Those derived outputs matter. Spectrograms, annotations, detections, notebooks, filtered files, and reports often explain whether a capture has already been useful and how someone interpreted it.

The exact checklist changes by team. The pattern does not: RF data gets more reusable when the searchable record contains the details people remember and the details they need to verify.

Filenames are not enough

Filenames carry a lot of weight in RF workflows because they are easy and visible.

A good filename helps. So does a clean folder structure. So does an object key that includes project, date, and sensor. The mistake is expecting those conventions to carry the whole workflow.

Filenames get shortened. Teams disagree on naming patterns. A file gets renamed for one analysis task. A folder gets copied into another project. A timestamp gets written in local time in one place and UTC somewhere else. A center frequency gets rounded. A later derived file keeps part of the original name but loses the collection details.

Spreadsheets have similar problems. They are useful until there are too many files, too many copies, too many people, or too many security boundaries. Scripts can help, but they often become local knowledge. Memory works until the one person who remembers the test is busy, reassigned, or gone.

None of these tools are bad. They are normal. They just are not enough by themselves for long-lived RF data.

A practical metadata checklist for IQ captures

A useful checklist should be boring enough that teams will actually use it.

For each capture, start with the fields needed to answer four questions later.

First: what was collected? That includes center frequency, sample rate, bandwidth, duration, file format, capture type, and any known signal labels.

Second: where did it come from? That includes sensor, receiver, antenna, location, test event, collection system, operator or automation source, and relevant configuration.

Third: can this team use it? That includes access controls, classification or handling notes where applicable, data owner, project, customer, releasability, and retention expectations.

Fourth: what happened after collection? That includes checksums, ingestion time, preview products, annotations, derived files, notebooks, detections, reports, and links back to the raw capture.

The goal is not to create a perfect ontology before anyone can save data. That usually fails. The goal is to make the common questions searchable and to leave room for more detail when a program needs it.

Metadata can arrive in more than one way

One reason RF metadata gets messy is that it does not all come from the same place.

Some fields come from the file format or sidecar metadata. SigMF can carry useful capture and annotation details. Other formats may expose sample rate, frequency, timestamps, or device settings. Some fields come from the collection system. Some come from an operator note. Some come from a lab notebook, mission log, ticket, or test plan. Some are added later during analysis.

A realistic RF data workflow has to accept that mixed reality.

It should preserve the original file. It should extract what it can. It should let humans add context that the file never contained. It should keep derived outputs connected to the original capture. It should make uncertainty visible instead of pretending every field is complete.

That last part matters. Bad metadata can be worse than missing metadata if people trust it blindly. A useful system should make it clear where a field came from and whether it was extracted, entered, inferred, or updated later.

How we think about this in SigDrive

SigDrive is being built around a simple idea: large RF captures should remain findable and understandable after the original collection is over.

Metadata is central to that. The product direction is to treat each capture as a record with searchable RF context, not as a blob sitting somewhere in storage. That means ingestion, metadata extraction where available, user-supplied fields, spectrogram preview, access control, audit history, and links to derived analysis all need to stay connected.

We should be careful about overclaiming here. No product can magically recover context that was never recorded. If the collection setup was not documented and the file format does not contain it, software cannot invent the truth.

But software can make the right behavior easier.

It can prompt for the fields teams commonly need. It can keep metadata attached to the capture instead of scattered across folders and spreadsheets. It can make search match how engineers remember data. It can preserve links between raw captures and derived outputs. It can support controlled deployment environments where RF data cannot leave the network.

That is the direction we are taking with SigDrive.

If your team has old IQ captures that technically exist but are hard to find, understand, or trust, we would like to compare notes.