Long-term Raw I/Q data request

Satellites & Observations
,
1

Hi all,

I’m having fun with a small side project looking to recognise RF signals with a machine learning algorithm to optimise ground station usage for space applications. I was wondering if it were possible to have the raw I/Q data from as many observations from as many different small satellites as possible over the course of a few weeks/a month for example from a well equipped station (to give consistent quality recordings) - something similar to the EIRSAT-1 ground station.

Is there somewhere where the raw data from observations is stored? Or this is avoided due to the size of the files? Would anyone be willing to help me out with this request?

Thanks in advance!

2

open source project?

3

Honestly haven’t thought about it yet. We’re considering writing a paper on it but for right now we’re just some nerdy friends playing around for fun

1 Like
4

Our stations [BEEGND-1]( SatNOGS Network - Ground Station BEEGND-1 ) and [BEEGND-4](SatNOGS Network - Ground Station BEEGND-4) upload their doppler-corrected IQ-Data from the satnogs client directly into our nextcloud. You can get them from there:

As our quota is limited, I regularly delete old observations there per script. Feel free to schedule and fetch the data.

2 Likes
5

SUPERZZZ

6

This is awesome, thank you so much!

7

The Dwingeloo radio telescope recordings are also available online: SatNOGS IQ data

1 Like
8

For this kind of work, I think the raw I/Q files are only half of the dataset.
The associated metadata is just as important if the goal is to make the data reusable and comparable across stations or processing pipelines. Some public IQ archives already expose useful observation-level metadata, such as observation id, date/time, satellite, status and sometimes decoded telemetry links. That is already very helpful.

For ML-oriented reuse, though, I would still try to keep a small machine-readable manifest per recording with satellite/NORAD id, observation id if available, station id, timestamp, center frequency, sample rate, sample format, doppler correction status, pass information and any known decoder/result associated with that recording. Witout that context, the files may still be useful, but reproducing results or comparing different observations later becomes much harder.

9

I ever wanted the client to write real sigmf-files. Most of the metadata you mention can be added there. Plus: It’s an emerging open standard.

2 Likes
10

Good point, yes. SigMF is probably the right direction here, much better than inventing an ad-hoc manifest format. The useful part would probably be a small SatNOGS-specific SigMF extension or convention for the mission/observation context that is not purely capture-level: observation id, station id, satellite/NORAD id, Doppler correction status, and possibly decoder/result links when available. That would keep the IQ recordings aligned with an existing open standard, while making them easier to reuse across ML experiments and downstream tools.

11

Station 4451 :

SatNOGS IQ data

1 Tera Archieves:
https://hobisatelit.github.io/iq

12

I’ve updated the stations to upload .tar.zst archives with sigmf-data. Preliminarily, the metadata is just link by an url to the observations on satnogs-network. It is not that easy to get everything within a post-observation script.

{
    "global": {
        "core:author": "Op of Satnogs-Station 106",
        "core:datatype": "ci16_le",
        "core:description": "Doppler corrected IQ capture of SatNOGS-Observation https://network.satnogs.org/api/observations/14052854",
        "core:num_channels": 1,
        "core:offset": 0,
        "core:sample_rate": 57600,
        "core:sha512": "7f3f01f1f770861d703ee6b1d62ca86bfda0eaf3616e08338ddb31c5b7d1544535fef1a8d87f861a1b6ade028ee7b2e918bc624509fc8421dee5e65345edee76",
        "core:version": "1.10.0"
    },
    "captures": [
        {
            "core:datetime": "2026-05-13T02:24:44",
            "core:frequency": 437325000,
            "core:sample_start": 0
        }
    ],
    "annotations": []
}
2 Likes
13

That is a very nice step forward.

Linking the SigMF recording back to the SatNOGS observation URL already solves a large part of the provenance problem, especially if the post-observation script does not have easy access to all the context locally.

Maybe a practical split could be:

  1. keep the station-side writer simple and robust: SigMF data, core capture metadata, checksum, observation URL;
  2. optionally enrich the archive later from the SatNOGS Network API, using the observation URL as the key.

That second step could add SatNOGS-specific context such as observation id, station id, satellite/NORAD id, transmitter/mode, Doppler correction status, and decoder/result links if available.

This would keep the capture side clean while still allowing ML or downstream tools to work with richer metadata when needed.
F.

14

Can you share some details on how the sigmf data and meta is created.

Jan | PE0SAT

1 Like