Earth Orientation Parameters — Robotics/Celestial Phenomena
Robotics/Celestial_Phenomena/Earth_Orientation_Parameters · 1 input / 3 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
Earth Orientation Parameters
Robotics / Celestial Phenomena
The Earth's orientation as the International Earth Rotation and Reference Systems Service (IERS) measures it, for one UTC date given as a Modified Julian Date: the three corrections an ECI–ECEF transformation takes, read out of the IERS table.
- dUT1 = UT1 − UTC, in seconds
- polar motion x and y, the table's arcseconds × π/648000
- celestial pole offsets ΔX and ΔY, the table's milliarcseconds × π/648000000
It is a lookup, and a step rather than an interpolation: the values tabulated for a UTC day hold for the whole of that day, so a date of 60779.75 reads the row for 60779.
- before the table (MJD below 49364, 12 January 1994) the first day's values are held
- after the table the last row's values are held – the pole offsets' column ends 299 days earlier than the others, at MJD 60779 (14 April 2025), and holds its own last row from there
- from one day past the last row (MJD 61079 and later) dUT1 is −0.9, which is what the reference answers there for every date
The table is the IERS finals2000A series as MATLAB R2026a ships it
(aeroiersdata.mat), one row per day from MJD 49364 to 61078
(7 February 2026). Rows from MJD 60706 on (from 60690 for the pole
offsets) are the IERS's predictions rather than measurements.
Ports
- mjd – the UTC date as a Modified Julian Date (Julian date − 2400000.5), in days, fractions allowed. A scalar [1,1].
- dUT1 – UT1 − UTC in seconds, [1,1].
- xp_yp – polar motion along x and y, in radians, [2,1].
- dX_dY – the celestial pole offsets ΔX and ΔY, in radians, [2,1].
The three outputs are shaped and ordered as the ECI To ECEF Rotation Matrix block's dUT1, xp_yp and dX_dY inputs, so they wire straight across.
Parameters
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
Seven targets: Python, MATLAB, Java, Rust, C, C++ and PLC Structured Text. Each carries the table's five columns – 57977 numbers, written as the shortest decimals that read back as the same doubles – and one lookup, so every target answers exactly what the block's own simulation answers. Java receives the columns as text parsed once, because array literals that long exceed a Java method's size limit.
The three HDL targets (VHDL, Verilog, SystemVerilog) are not offered – an export to one of them stops and names this block – because a Modified Julian Date (about 49000 to 61000) cannot sit on a Q16.16 port, whose range ends at ±32768, so a hardware core would read a saturated date and answer one row of the table.
Simulink bridge
Import and export, mapped to Aerospace Blockset's
aerolibcelestial/Earth Orientation Parameters. No configuration
value crosses. Three Simulink parameters are always implied:
FileName is aeroiersdata.mat, the table this block carries;
OutputError is off, since that setting adds three more
output ports carrying the table's error estimates and no configuration here can
add a port; and action is Warning, that parameter only
choosing whether Simulink reports a date outside the measured data. An import
that names another value for any of them is reported rather than silently
accepted. The Simulink block defines no SampleTime
parameter, measured, so the rate stays on the ICore side. The global
Sampling Time (s) → SampleTime pair therefore does not
cross.
Notes
- Algebraic and stateless: the outputs depend on this sample's date alone.
- Not linear, so the block carries no state space and model reduction correctly reports it as unmergeable.
- The table is a snapshot: the IERS republishes it weekly, and dates past its end read held values until the block's table is refreshed.
- Verified bit for bit against R2026a's block, all three outputs, on every row boundary, at fractional dates and on both sides of both ends of the table.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Celestial_Phenomena/Earth_Orientation_Parameters |
| family | Robotics/Celestial_Phenomena |
| solver environment class | ICoreBlock_0_Robotics_1_Celestial_Phenomena_2_Earth_Orientation_Parameters |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Celestial_Phenomena/Earth_Orientation_Parameters/ICoreBlock_0_Robotics_1_Celestial_Phenomena_2_Earth_Orientation_Parameters.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Celestial_Phenomena/Earth_Orientation_Parameters/ICoreBlock_0_Robotics_1_Celestial_Phenomena_2_Earth_Orientation_Parameters.h |
| default size on canvas | 150 × 100 px |
| ports at insert | 1 in, 3 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | mjd |
| 2 | out | ICoreDouble | dUT1 |
| 3 | out | ICoreDouble | xp_yp |
| 4 | out | ICoreDouble | dX_dY |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
No config variable beyond the Sampling Time (s) every block carries.
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::Both |
| Simulink path | aerolibcelestial/Earth Orientation Parameters |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | FileName = aeroiersdata.mat, OutputError = off, action = Warning |
Caveat (shown to the user): one input, the UTC date as a Modified Julian Date, and three outputs: UT1-UTC in seconds, the polar motion [x; y] in radians and the celestial pole offsets [dX; dY] in radians, read from the IERS table as a previous-day step. 'FileName' is always aeroiersdata.mat (the table this block carries), 'OutputError' always off (it adds three error-estimate output ports, and no configuration here can add a port) and 'action' always Warning (it only chooses whether Simulink reports a date outside the measured data). The Simulink block has no SampleTime, so the rate stays on the ICore side
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
Earth Orientation Parameters -- dUT1, polar motion and the pole offsets from the IERS table i = the last tabulated UTC day at or before the input MJD dUT1 = UT1-UTC(i) (-0.9 from one day past the table) xp_yp = [x(i); y(i)] * (pi/648000) arcseconds to radians dX_dY = [dX(j); dY(j)] * (pi/648000000) milliarcseconds to radians, j = min(i, last)
The table is the one MATLAB R2026a ships as aeroiersdata.mat, the Simulink block's default data file, so at its defaults the Simulink block reads exactly these numbers.
⚠ MEASURED AGAINST R2026a, not read: the block is a built-in type with no readable source. All three outputs agree BIT FOR BIT on every row boundary, at fractional dates and on both sides of both ends of the table, including the pole offsets' own shorter end -- see ICoreIersSupport.cpp.
ALGEBRAIC and STATELESS, and nonlinear in its input, so no state space.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 | out ICoreDouble-Out-1 [2x1] entry 0 | out ICoreDouble-Out-2 [2x1] entry 0 |
|---|---|---|---|---|
| 0 | -2 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 0.4 | 0.5 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 0.8 | -2 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 1.2 | 0.5 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 1.6 | -2 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 2 | 0.5 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 2.4 | -2 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 2.8 | 0.5 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 3.2 | -2 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 3.6 | 0.5 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 4 | -2 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 4.4 | 0.5 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 4.8 | -2 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
| 5.2 | 0.5 | 0.1732 | [1.855e-7, 2.326e-6] | [-1.886e-9, -1.648e-10] |
Every 4th of 60 samples, from the table stimulus.
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0.1732 … 0.1732 |
ramp | Ramp: slope 1 from t = 0 | 0.1732 … 0.1732 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 0.1732 … 0.1732 |
step | Step: 0 -> 1 at t = 1 s | 0.1732 … 0.1732 |
Plotted: table — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample
Category static · sample time 0.1 · 60 steps · commit 4e9a69f500134584b65a757784a6b10fb1e5b1c7 · produced by docsSample --out <folder> --blocks Delta_UT1 Earth_Orientation_Parameters --steps 60 · data docs/generated/samples/Robotics__Celestial_Phenomena__Earth_Orientation_Parameters.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).