# Unit orientation/mirror matrix explained

Hello,
how do I interpret the orientation and mirror style of a unit in the schematic file ? It is pretty cryptic specified in lines as show below. I commented their individual results, but I can only guess how to read it.

1 0 0 -1 #orientation 0, mirror normal
0 -1 -1 0 #orientation 90, mirror normal
1 0 0 1 #orientation 180, mirror normal
0 1 1 0 #orientation -90, mirror normal

1 0 0 1 #orientation 0, mirror –
0 -1 1 0 #orientation 90, mirror –
1 0 0 -1 #orientation 180, mirror –
0 1 -1 0 #orientation -90, mirror –

1 0 0 -1 #orientation 0, mirror |
0 1 -1 0 #orientation 90, mirror |
1 0 0 1 #orientation 180, mirror | , probably a bug ?
1 0 0 1 #orientation -90, mirror | , probably a bug ?

I looked at the source code and found that these appear to represent a 2d transformation matrix[1].

The matrix is x1, y1, x2, y2, which I assume is:

``````x1  y1
x2  y2
``````

Then I needed a review of 2d transformation[2] The important section for us is the left side of page 3 (I don’t see how to post pictures from mobile).

The final matrix can’t be explained by simple mirror and rotate because it depends on the order of operation. For example, the following are equal:
Rotate -90, vert mirror
Horiz mirror, rotate -90.
(Try it with your hand, I did )

Note that the “normal” you’ve indicated is a transformation matrix of

``````1   0
0  -1
``````

and is equivalent to a vertical mirror (see reference [2]. This is transforming +y up to +y down, which may be because KiCad coordinates on screen are +y down. It’s possible the screen translation happens elsewhere, this is just a guess.

Based on this, you hopefully can derive the answer you need.

1 Like

A little experiment later, looks like eeschema applies Mirror before Orientation, as listed in the properties.
so if you rotate CCW first (which is +90) then mirror horizontal, the properties will be mirror horizontal and orientation -90 (which is CW). It’s kind of the difference between ‘action’ and ‘state’ where actions can be done in any order (rotate, flip) and state is defined as a flip in the mirror direction occurring before the orientation applied as a rotation.

Thanks for your help. I’m still trying to understand what you wrote. However, the last two lines in my initial post seem to be wrong written by eeschema (version 4.0.5) as they are exactly the same for a different orientation. I presume the last four lines as a whole are wrong. Can anyone confirm my assumption ?

When you say “different orientation” do you mean you applied different rotation/flip commands, or do you mean it looks differently rotated/flipped on screen?

1 Like

In eeschema, when I apply the orientation 180 or -90 on a unit combined with “mirror |” then eeschema writes the mentioned lines in the schematic design file. I expect them to differ but they don’t. So I suspect a bug.

It’s a not a bug, but it took me a little while to work out.

Only rotation and X mirror (–) are required to describe all possible states. Although Y mirror (||) is given as a command for the user, it is implemented as an equivalent combination of rotation and X mirror, and only those properties are stored in the schematic. Only the first 8 lines you describe are used.

That has the result that what is shown in Component Properties may change when you reload the schematic.

Is there are reason why you need to decode these lines, or is it just for general interest?

Right, mirroring along the Y axis is not required:

• line 5 equals line 11
. line 6 equals line 12
• line 7 equals line 9
• line 8 equals line 10

However, I think line 12 should read: 0 -1 1 0 (like line 6).
When eeschema reads a schematic it is likely to interpret such a line as a “mirror-X-rotate-0-degree-operation”.

The reason for decoding the schematic is to read the schematic into a design rule check tool (entirely different from KiCad) in order to check designs for safety critical applications.

KiCad reads in the 4 values then matches them to a hardcoded list of transforms, the first one that matches is the one it uses. It does actually have all 12, but only the first 8 will ever be matched.

I have some C# code to read the schematic, and I adopt a similar but simplified approach,
``````        public void SetOrientation(int A, int B, int C, int D)
{
Rotation = 0;
Mirror = false;
for (int index = 0; index < orientations.Count; index++)
{
if ((A == orientations[index][0]) &&
(B == orientations[index][1]) &&
(C == orientations[index][2]) &&
(D == orientations[index][3]))
{
Rotation = (index % 4) * 90;
if (index > 3)
Mirror = true;
}
}
``````
1 Like

ok, thanks for all your contributions and help. I think the case is closed now. Proceed