B1950 To J2000 — Robotics/Coordinate Transforms
Robotics/Coordinate_Transforms/B1950_To_J2000 · 2 input / 2 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, 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.
B1950 To J2000
Robotics / Coordinate Transforms
Moves a position and a velocity from the B1950 (FK4) reference frame to J2000 (FK5). The two vectors are stacked into one six-element state and multiplied by a single constant 6×6 matrix:
- [r'; v'] = M · [r; v]
M is the constant the Aerospace Blockset block carries, transcribed exactly.
⚠ This is not a rotation of the position alone. The matrix's bottom-left 3×3 carries the frame's rotation rate, so the output velocity depends on the input position – entries near 0.44 against a position in kilometres. Rotating each vector separately would agree on r and be wrong on v.
⚠ Nothing here converts an epoch number. The Aerospace Blockset calls this block an epoch conversion, and the names B1950 and J2000 do name epochs – but what crosses is a state vector between two reference frames, measured inside the Simulink mask rather than read off its name.
Ports
- r_B1950 – the position in the B1950 (FK4) frame, a [3,1] column. Its units are whatever the caller uses; the matrix is dimensionless in its leading block.
- v_B1950 – the velocity in the B1950 (FK4) frame, also [3,1].
- r_J2000 – the position in J2000 (FK5), [3,1]. Its size is fixed and does not follow the inputs'.
- v_J2000 – the velocity in J2000 (FK5), [3,1].
Parameters
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The matrix is structural – it is the frame pair, not a value a user retunes after export – so it is inlined into the arithmetic rather than exposed as a tunable parameter.
The three HDL targets are genuinely synthesizable Q16.16, not simulation-only: thirty-six multiplies and thirty summations, with no division, root or trigonometry. Each six-term sum is formed at full width and brought back to Q16.16 once, so the rounding lands on the sum rather than on every product.
⚠ Four of the thirty-six coefficients are smaller than the Q16.16 quantum and therefore land at zero in hardware. The largest of them is 2.4×10−6, so against a position of order 104 it contributes about 0.02 – five orders below the term beside it. The seven software targets carry every coefficient exactly.
Simulink bridge
Both directions, onto aerolibtransform2/Besselian Epoch to Julian Epoch in the Aerospace
Blockset. The block has no dialog parameter at all, so nothing but the
two signals crosses.
Its name is drawn on two lines, so the real library path carries an
embedded newline. And the block defines no SampleTime
parameter, so the rate stays on the ICore side and a block configured with an
explicit positive rate reports that the rate did not cross.
Notes
- Algebraic and stateless: the outputs depend only on the current inputs, so the block cannot break an algebraic loop.
- J2000 To B1950 is the exact inverse, and it is a true matrix inverse rather than a transpose – the matrix is not orthogonal.
- Deliberately no state space. The block is linear, but it has no dynamics at all – a feed-through state space for it would carry a dummy state that tells a reader nothing the matrix does not.
Code facts#
| Fact | Value |
|---|---|
| registered type | Robotics/Coordinate_Transforms/B1950_To_J2000 |
| family | Robotics/Coordinate_Transforms |
| solver environment class | ICoreBlock_0_Robotics_1_Coordinate_Transforms_2_B1950_To_J2000 |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Coordinate_Transforms/B1950_To_J2000/ICoreBlock_0_Robotics_1_Coordinate_Transforms_2_B1950_To_J2000.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Robotics/Coordinate_Transforms/B1950_To_J2000/ICoreBlock_0_Robotics_1_Coordinate_Transforms_2_B1950_To_J2000.h |
| default size on canvas | 128 × 84 px |
| ports at insert | 2 in, 2 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | r_B1950 |
| 2 | in | ICoreDouble | v_B1950 |
| 3 | out | ICoreDouble | r_J2000 |
| 4 | out | ICoreDouble | v_J2000 |
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 | aerolibtransform2/Besselian Epoch\nto Julian Epoch |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
Caveat (shown to the user): the Aerospace Blockset block is a masked subsystem with NO dialog parameters, so nothing but the two signals crosses. ⚠ Its name says "epoch" and it does not convert one: measured inside the mask, it multiplies a stacked [position; velocity] by one constant 6x6 matrix, which is a change of reference FRAME. Note it defines no SampleTime parameter: an ICore rate set explicitly stays on this side and is reported
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:
B0no sample under docs/generated/samples/ — nothing to cross-check (P8.1)
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).
B1950 To J2000 -- a position and velocity across the FK4/FK5 frame change Two [3,1] inputs (position and velocity in B1950 (FK4)) and two [3,1] outputs (the same pair in J2000 (FK5)). The two vectors are stacked into one six-element state and multiplied by a single constant 6x6 matrix:
[ r' ] [ M11 M12 ] [ r ] [ v' ] = [ M21 M22 ] [ v ]
M is the matrix the Simulink block holds; the reverse block uses its inverse.
MEASURED against aerolibtransform2/Besselian Epoch to Julian Epoch in R2026a on 2026-09-10, by looking INSIDE the masked subsystem rather than trusting its name: it holds one Constant called
rotmatand one Product, and the Product's mode is what separates this block from its inverse. On r = [7000.1, -1200.35, 430.7] and v = [1.25, 7.31, -0.48] the Simulink block and the matrix product agree at EXACTLY zero difference.⚠ THE BOARD ROW CALLED THIS AN "epoch" CONVERSION AND IT IS NOT ONE. Nothing here converts an epoch NUMBER between the Besselian and Julian conventions; the block moves a state vector between two reference FRAMES whose names carry those epochs. The Simulink port labels say so in as many words -- r_B1950, v_B1950 in and r_J2000, v_J2000 out -- and the finding is on the board.
⚠ IT IS NOT A ROTATION OF THE POSITION ALONE. The matrix's bottom-left 3x3 carries the frame's rotation RATE, so the output VELOCITY depends on the input POSITION, with entries near 0.44 against a position in kilometres. A block that rotated each vector separately would agree on r and be wrong on v -- which a spot check of the first output cannot see.
Multiply-add only, no division and no trigonometry, so all three hardware targets are GENUINELY SYNTHESIZABLE Q16.16 rather than simulation-only.
Sample results#
No sample run is committed for this block. Samples come from the headless harness (DOCS_PLAN.md P8.1) into docs/generated/samples/; until one exists this block's behaviour is witnessed by the parity and export-verification suites, not by a plot here.