According 61850-8-1 and 9506-1, the INT8U when highest bit is set shall be encoded with length 2 (now is 1) - like INT8, where the highest bit is sign. So, mapped on MMS e.g. value 255 (FFh) shall be 86 02 00 FF but is now 86 01 FF. Issue affects all unsigned integer types (INT16U, INT32U etc).
According 61850-8-1 and 9506-1, the INT8U when highest bit is set shall be encoded with length 2 (now is 1) - like INT8, where the highest bit is sign. So, mapped on MMS e.g. value 255 (FFh) shall be 86 02 00 FF but is now 86 01 FF. Issue affects all unsigned integer types (INT16U, INT32U etc).
Issue was addressed in encoding of UNSIGNED integers. Now, both drivers are using the same encoding size in mms for signed and unsigned values,
e.g.: when INT8U variable has value:
where vv = variable value
issue typically does not cause communication problems as almost all clients and servers on market are correctly handling also values encoded to shorter notation (supported in all popular MMS stacks).