I have a workflow that applies orbit files to Sentinel-1 GRD images (default to precise, fall back to resorb) with the auto-download option.
Looking at the location where these orbit files come from:
it looks like it’s been paused since March 2. Has this auto-download functionality been deprecated? I know it’s possible to fetch these from the CDSE odata API or from s3 with credentials from CDSE but it would be great if we could continue to use the auto-download functionality.
We are also experiencing this for S1A imagery from March 4th:
org.esa.snap.core.gpf.OperatorException: No valid orbit file found for 04-MAR-2026 14:15:58.303115
Same issue with S1A and S1C for images captured in February and March 2026. Example image: S1A_IW_GRDH_1SDV_20260308T003348_20260308T003413_063529_07FBA3_F419
Edit: Happens with precise and restituted orbit files. Tested on SNAP 11-13
Cross-posted on the CDSE forum: forum.dataspace.copernicus.eu/t/missing-sentinel-1-orbit-files/4845
Experiencing the same issue
As a workaround, this tool might be able to help with downloading the orbit files from an alternative source: GitHub - scottstanie/sentineleof: Download Sentinel 1 precise orbit files · GitHub
The files need to be then placed where SNAP expects to find them, for example: ~/.snap/auxdata/Orbits/Sentinel-1/RESORB/S1A/2026/03
We are currently working on fixing this issue and will update this thread once the problem has been resolved.
The orbit files should now be available for download.
Experiencing the same issue
@muzammil098 are you still experiencing this issue with the RESORB files?
Hi,
currently i also experience orbit file issues for many images in March across Europe.
Example Snap exception:
Caused by: java.io.IOException: No valid orbit file found for 22-APR-2026 18:18:46.634663
Orbit files may be downloaded from Copernicus Dataspaces
In the AWS bucket AWS S3 Explorer I can’t find an orbit file matching S1A_IW_GRDH_1SDV_20260422T181953_20260422T182018_064196_081498_D588. The latest orbit file for this date I found is
S1A_OPER_AUX_RESORB_OPOD_20260422T184016_V20260422T145112_20260422T180842.EOF
which is 10 min to early for this image.
@alfredoahds: Is the issue still occuring for you or is it me doing sth wrong right now?
Hi,
i just confirmed,
is missing the required orbit file as well
Hi, Are there any updates yet?
Dear David,
The orbit files available on the STEP server are downloaded from the Copernicus Dataspace. Unfortunately, the required RESORB orbit file is not available on the Copernicus Dataspace either.
There was an anomaly on that day that probably explains missing data. What kind of orbit info is available in the metadata of the satellite product itself?
Well, the raw acquisition data is there. I’d treat orbit files more as metadata. Sure, in the downloaded product there is the basic orbit information (orbit state vectors), but I think they are the predicted ones and quite inaccurate. i would like to apply resitude or precise orbit files.
The Restitude orbit files never became available, but now the precise orbit files are available and I soon cannot claim it a bug any more, since the dataspace states it only keeps the Restitude orbit file in a 30 day rolling window which closes 22th May. Either way, as @diana_harosa pointed out, the issue is a copernicus responsibility and I will open a thread there (https://forum.dataspace.copernicus.eu/) if it surfaces again.
Which type of orbits are in the SAR product itself?
To my knowledge only the predicted ones, which are far less accurate than restitude, which are again less accurate than precise
The type of orbits inside the product depends on when it was processed. Now there are also MOE-orbits that are already vey very good (almost as good as precise orbits) and available 24 hours after sensing. Do a double-check you might get lucky.
Ah ok, thanks. That makes sense. As postet earlier, the current issue has been solved by precise orbit publication, but in the future I’ll check the orbit info in the products.
Look into the MOE-orbits, for most InSAR users the difference to POE is negligible.