Delta UT1 — Robotics/Celestial Phenomena
Robotics/Celestial_Phenomena/Delta_UT1 · 1 input / 1 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.
Delta UT1
Robotics / Celestial Phenomena
The difference between UT1, the time scale kept by the Earth's rotation, and civil UTC, for a UTC date given as a Modified Julian Date: dUT1 = UT1 − UTC, in seconds, read out of the International Earth Rotation and Reference Systems Service (IERS) table.
It is a lookup, and a step rather than an interpolation: the value tabulated for a UTC day holds 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 value is held
- from one day past the last row (MJD 61079 and later) the answer 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 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. Any size [m,n]; the block works entry by entry.
- dUT1 – UT1 − UTC in seconds, the same size as mjd. Its magnitude never exceeds 0.9 s.
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 – 11715 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 table as text parsed once, because an array literal that long exceeds 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/Delta UT1 (the same block appears under Axes
Transformations). No configuration value crosses. Two Simulink parameters are
always implied: FileName is aeroiersdata.mat, the table
this block carries, and action is Warning, that parameter
only choosing whether Simulink reports a date outside the measured data; an
import that names another value 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 output depends 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 from 8 February 2026 on read the saturated −0.9 until the block's table is refreshed.
- Verified bit for bit against R2026a's block 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/Delta_UT1 |
| family | Robotics/Celestial_Phenomena |
| solver environment class | ICoreBlock_0_Robotics_1_Celestial_Phenomena_2_Delta_UT1 |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Celestial_Phenomena/Delta_UT1/ICoreBlock_0_Robotics_1_Celestial_Phenomena_2_Delta_UT1.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Celestial_Phenomena/Delta_UT1/ICoreBlock_0_Robotics_1_Celestial_Phenomena_2_Delta_UT1.h |
| default size on canvas | 120 × 70 px |
| ports at insert | 1 in, 1 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 |
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/Delta UT1 |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | FileName = aeroiersdata.mat, action = Warning |
Caveat (shown to the user): one input, the UTC date as a Modified Julian Date, and one output, UT1-UTC in seconds, read from the IERS table as a previous-day step. 'FileName' is always aeroiersdata.mat (the table this block carries) 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).
Delta UT1 -- UT1 - UTC from the IERS table dUT1 = UT1-UTC(i), i = the last tabulated UTC day at or before the input MJD
held at the first day before the table, and -0.9 from one day past its last row. The table is the one MATLAB R2026a ships as aeroiersdata.mat, which is 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. A previous-row step, bit for bit, on every row boundary, on both sides of both ends of the table and at fractional dates -- 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 |
|---|---|---|
| 0 | -2 | 0.1732 |
| 0.4 | 0.5 | 0.1732 |
| 0.8 | -2 | 0.1732 |
| 1.2 | 0.5 | 0.1732 |
| 1.6 | -2 | 0.1732 |
| 2 | 0.5 | 0.1732 |
| 2.4 | -2 | 0.1732 |
| 2.8 | 0.5 | 0.1732 |
| 3.2 | -2 | 0.1732 |
| 3.6 | 0.5 | 0.1732 |
| 4 | -2 | 0.1732 |
| 4.4 | 0.5 | 0.1732 |
| 4.8 | -2 | 0.1732 |
| 5.2 | 0.5 | 0.1732 |
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__Delta_UT1.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).