<p>The TESS file format is described in Section 2.1 of the <a href="https://archive.stsci.edu/missions/tess/doc/EXP-TESS-ARC-ICD-TM-0014.pdf" rel="nofollow noreferrer">TESS Science Data Products Description Document</a> (data at the major archives such as MAST, IPAC/NEXSci or PDS should always have one of these data product documents that describe the data format, contents and issues or gotchas and so they are well worth hunting down first). That section breaks down and explains the format for all the TESS data products, not just the Full Frame Images. For the <code>_ffic</code> files, which you correctly guessed are calibrated fullframe images, we have (quotes from the document in <em>quotation marks</em>):</p>
<p><code>tess&lt;yyyydddhhmmss&gt;-s&lt;sctr&gt;-&lt;cam&gt;-&lt;ccd&gt;-&lt;scid&gt;-&lt;cr&gt;_ffic.fits.gz</code>
where:</p>
<ul>
<li><code>&lt;yyyydddhhmmss&gt;</code> is an UTC timestamp which Section 2.4.1 says &quot;<em>is usually the start of the spacecraft pointing time</em>&quot;.</li>
<li><code>&lt;sctr&gt;</code> is indeed the sector number (with a <code>s</code> prefix), which &quot;<em>is a 4 digit zero-padded integer indicating the sector in which the data were collected</em>&quot;</li>
<li><code>&lt;cam&gt;</code> is a single digit that camera number which can be &quot;1&quot;, &quot;2&quot;, &quot;3&quot;, or &quot;4&quot;.</li>
<li><code>&lt;ccd&gt;</code>, is a single digit that identifies CCD chip and can also be one of &quot;1&quot;, &quot;2&quot;, &quot;3&quot;, or &quot;4&quot;.</li>
<li><code>&lt;scid&gt;</code> &quot;<em>is a four digit zero padded identifier of the spacecraft configuration map used to process this data.</em>&quot; (I wouldn't worry about this one, it probably only means something to the engineers...)</li>
<li><code>&lt;cr&gt;</code>, refers to the cosmic ray mitigation performed. Quoting &quot;<em>The value of this file name parameter will be 'x' if no mitigation at the SPOC (Science Processing Operations Center) was performed, 's' when mitigation
was performed on the spacecraft, the value will be 'a' to indicate that a SPOC mitigation algorithm was used, and 'b' to indicate that both the SPOC algorithm and the the spacecraft algorithm was used.</em>&quot;</li>
</ul>
<p>The other possible data types such as the target pixel data, light curves etc are also described in the Table 1. The document then goes onto to describe each product in more detail, starting with Full Frame Images in Section 3.</p>

CC BY-SA 4.0
2021-12-16T16:58:37.470Z
Ah yes those documents seems to be the thing indeed. I'm really more of a CS background, seems like the way docs/references as organized/presented differ between the 2 worlds. Didn'ht happen onto those (or missed their role/significance). Thanks.
Francky_V
CC BY-SA 4.0
2021-12-16T17:05:59.390Z
I think both worlds hate doing documentation, just the ones with the publicly-funded mission data don't get to skip completing the docs... ;-)
astrosnapper
CC BY-SA 4.0
2021-12-16T02:46:21.667Z
2021-12-16T02:46:21.667Z
astrosnapper
<p>I'm following <a href="https://spacetelescope.github.io/notebooks/notebooks/MAST/TESS/beginner_how_to_use_ffi/beginner_how_to_use_ffi.html" rel="nofollow noreferrer">this</a> and downloading &amp; displaying the TESS image file in matplotlib. That works great.</p>
<p>Now I'm trying to write myself a wrapper that allows me to specify in some config files what I want to get from that repo, &amp; process them iteratively. In order to build a sensible/flexible structure, I need to better understand the syntax/naming convention. For instance, let's consider the first curl url for the <a href="https://archive.stsci.edu/tess/bulk_downloads/bulk_downloads_ffi-tp-lc-dv.html" rel="nofollow noreferrer">calibrated FFIs for sector 43</a>:</p>
<ul>
<li><a href="https://mast.stsci.edu/api/v0.1/Download/file/?uri=mast:TESS/product/tess2021259224859-s0043-2-2-0214-s_ffic.fits" rel="nofollow noreferrer">https://mast.stsci.edu/api/v0.1/Download/file/?uri=mast:TESS/product/tess2021259224859-s0043-2-2-0214-s_ffic.fits</a></li>
</ul>
<p>If I break down the naming:</p>
<ul>
<li>tess2021259224859: datetime in format yyyyddmhhmmss ?</li>
<li>-s0043: sector in format sXXXXX</li>
<li>-2: camera number?</li>
<li>-2: ccd number?</li>
<li>-0214: ??</li>
<li>-s_ffic: s? ffic = full frame image calibrated?</li>
</ul>
<p>I'd like to better understand this in order to be able to parametrize the query urls in my application.</p>

<raw-data><tess>
Syntax for the naming of TESS data repository
Francky_V
# Syntax for the naming of TESS data repository

(Asked by: username_0 on 2021-12-15)

I'm following [this](https://spacetelescope.github.io/notebooks/notebooks/MAST/TESS/beginner_how_to_use_ffi/beginner_how_to_use_ffi.html) and downloading & displaying the TESS image file in matplotlib. That works great.

Now I'm trying to write myself a wrapper that allows me to specify in some config files what I want to get from that repo, & process them iteratively. In order to build a sensible/flexible structure, I need to better understand the syntax/naming convention. For instance, let's consider the first curl url for the [calibrated FFIs for sector 43](https://archive.stsci.edu/tess/bulk_downloads/bulk_downloads_ffi-tp-lc-dv.html):

* <https://mast.stsci.edu/api/v0.1/Download/file/?uri=mast:TESS/product/tess2021259224859-s0043-2-2-0214-s_ffic.fits>

If I break down the naming:

* tess2021259224859: datetime in format yyyyddmhhmmss ?
* -s0043: sector in format sXXXXX
* -2: camera number?
* -2: ccd number?
* -0214: ??
* -s\_ffic: s? ffic = full frame image calibrated?

I'd like to better understand this in order to be able to parametrize the query urls in my application.

**Tags:** raw-data, tess


---

## 1 answers

### Answer by username_1 on 2021-12-16. Score: 3 | Accepted answer

The TESS file format is described in Section 2.1 of the [TESS Science Data Products Description Document](https://archive.stsci.edu/missions/tess/doc/EXP-TESS-ARC-ICD-TM-0014.pdf) (data at the major archives such as MAST, IPAC/NEXSci or PDS should always have one of these data product documents that describe the data format, contents and issues or gotchas and so they are well worth hunting down first). That section breaks down and explains the format for all the TESS data products, not just the Full Frame Images. For the `_ffic` files, which you correctly guessed are calibrated fullframe images, we have (quotes from the document in *quotation marks*):

`tess<yyyydddhhmmss>-s<sctr>-<cam>-<ccd>-<scid>-<cr>_ffic.fits.gz`
where:

* `<yyyydddhhmmss>` is an UTC timestamp which Section 2.4.1 says "*is usually the start of the spacecraft pointing time*".
* `<sctr>` is indeed the sector number (with a `s` prefix), which "*is a 4 digit zero-padded integer indicating the sector in which the data were collected*"
* `<cam>` is a single digit that camera number which can be "1", "2", "3", or "4".
* `<ccd>`, is a single digit that identifies CCD chip and can also be one of "1", "2", "3", or "4".
* `<scid>` "*is a four digit zero padded identifier of the spacecraft configuration map used to process this data.*" (I wouldn't worry about this one, it probably only means something to the engineers...)
* `<cr>`, refers to the cosmic ray mitigation performed. Quoting "*The value of this file name parameter will be 'x' if no mitigation at the SPOC (Science Processing Operations Center) was performed, 's' when mitigation
  was performed on the spacecraft, the value will be 'a' to indicate that a SPOC mitigation algorithm was used, and 'b' to indicate that both the SPOC algorithm and the the spacecraft algorithm was used.*"

The other possible data types such as the target pixel data, light curves etc are also described in the Table 1. The document then goes onto to describe each product in more detail, starting with Full Frame Images in Section 3.

> **Comments:**
> **username_0**: Ah yes those documents seems to be the thing indeed. I'm really more of a CS background, seems like the way docs/references as organized/presented differ between the 2 worlds. Didn'ht happen onto those (or missed their role/significance). Thanks.  
> **username_1**: I think both worlds hate doing documentation, just the ones with the publicly-funded mission data don't get to skip completing the docs... ;-)  

---

