Overview

When a sculk sensor outputs a signal, it is currently either 1, 15, or even. Odd signal strengths apart from 1 and 15 are never produced.

Even though blocks on the diagonals are technically further away from the sensor than those directly on the axes, it will still output the same (even) value for both blocks. This issue makes the sculk sensor slightly inaccurate, especially in regards to triangulation.

This happens because the sculk sensor can only receive 9 different integer inputs for how far away a vibration is, and as the equation to calculate what redstone signal to output is a function, you will never be able to get more than 9 outputs out.

This results in the observed behaviour of no odd outputs being produced apart from 1 and 15.

The following screenshot shows which distance currently outputs which signal strengths, and which signal strengths they would output if the sculk sensor could receive a range of distance values from 0-8 as opposed to a discrete set of 9 values. (Click to zoom: MC-218222.png)

Sculk Sensor Output Visualisation (desmos)

Code Analysis

The game calls on the distance value which is an integer

This integer can only have 9 values because the range of the sculk sensor is 8 blocks (0-8), meaning that the function can only output a maximum of 9 values:

public static int getPower(int distance, int range) {
     double d = (double)distance / (double)range;
     return Math.max(1, 15 - MathHelper.floor(d * 15.0D));
}

The distance value seems to come from the SculkSensorListener class which initially comes from DistancePredicate and I am unsure as to how challenging it would be to calculate the distance as a double/float as opposed to an integer from the get-go.

Fix

The initial calculations for the distance value, wherever they are done, needs to be calculated as a double/float.

(The setup from this screenshot can be loaded via this structure file if you want to experiment with it yourself: mc-218222.nbt)

Video

This is a video showcasing a touchscreen display using sculk sensors, where this issue occurs in practice (two pixels cannot be distinguished from each other). The problem of the too imprecise outputs is mentioned and elaborated upon at the given timestamp.

https://youtu.be/y8gc6B_AmZE?t=498