TinyML Int8 Inputs: Convert Sensor Values with the Model’s Scale and Zero Point

The MCU accepts an int8 input tensor and Invoke succeeds, but predictions are consistently wrong. A byte with the right C type can still encode the wrong real-world value. Raw sensor counts, the model's normalized input and its quantized integer representation are separate quantities.

For a model with a single-scale int8 input, diagnose the conversion with a few known values before retraining the network or changing its decision threshold.

Read the tensor contract from the deployed model

The LiteRT quantization specification defines the represented real value as (q - zero_point) * scale. Input activations use the signed int8 range, including -128, and can have a nonzero zero point. Do not apply a symmetric weight tensor's zero-point rule to the application's input.

Read the actual input type, shape and quantization parameters. The Python interpreter reference exposes scales, zero_points and quantized_dimension through quantization_parameters. It marks the older quantization field as deprecated. When there is more than one scale, do not silently apply the single-scale procedure in this article to the entire tensor.

Check the output details separately. An output tensor does not automatically share the input's scale or zero point, and a classification output is not necessarily a probability merely because it contains several numbers.

Apply preprocessing before integer encoding

First determine the real-valued domain expected by the model. If training used normalized acceleration, an ADC count or a sensor value in another unit must pass through the equivalent normalization before quantization. If normalization is already inside the model graph, applying it again outside changes the input.

Next convert that real-domain value to the integer representation. The examined TFLM helper rounds value divided by scale, adds the zero point, and clamps the result to the destination type's limits.

A direct cast to int8 is not that operation. It omits scaling and offset, and casting an out-of-range intermediate is not a substitute for deliberate saturation. Validate a positive finite scale and finite, appropriately bounded input before conversion; do not assume the helper is a general sanitizer for corrupted metadata or arbitrary floating-point values.

Use values that expose offset and saturation errors

Consider an illustrative scale of 0.125 and zero point of -3. These values are chosen for simple arithmetic, not taken from a trained model:

• Real zero encodes as -3. Filling the tensor with integer zeros instead represents 0.375.
• Real 0.25 encodes as -1; real 1.0 encodes as 5.
• Real 20.0 would produce 157 before clamping. Its stored int8 value is 127, representing 16.25 after reconstruction.

The last case demonstrates information loss from saturation. Repeated endpoint values in a captured tensor deserve investigation: the source signal may be outside calibration coverage, preprocessing may be wrong, or the expected scale may belong to another model. Endpoint occupancy alone does not identify which cause applies.

Compare expected integers with the actual tensor immediately before Invoke. Include real zero, positive and negative values, range edges and values near rounding boundaries. Use the same rounding convention in the reference calculation and firmware; languages can differ at half-way cases.

Separate numeric mapping from tensor layout

Correct scalar conversions can still be placed in the wrong order. Confirm element count, axis order, channel order and temporal order against the model shape. A correctly quantized X-axis sample in a Y-axis position remains the wrong input.

Then reconstruct selected stored values with the model's scale and zero point. This catches offset and clipping mistakes without requiring a classification label to change. For outputs, use each output tensor's own parameters before applying a real-domain threshold.

Only after the input bytes, layout and output interpretation agree should classification quality become the primary investigation. This procedure verifies the firmware's numeric interface; it does not establish that the trained model is accurate for the device's environment. The example arithmetic was calculated locally, with no model inference or sensor experiment.