# Encoder/Channel Set problem with Readout = Decimal8

• I noticed this and it seems like a bug:

On a 16 bit Attribute I have a Channel Set with value 32768 only. (It is "No Rotation")

If I recall that with Readout = Decimal 8 the value that is recalled is 32896. (And that is a bit rotation)

Correct values for the DMX channels are 128 / 0 but for some reason it becomes 128 / 128

This seems connected to the behaviour that both the course and fine channel gets the same value when encoder is turned.

To top it off the outer encoder ring does not work in this mode.

Could anyone confirm and report this please?

• Same here,

but I'm also seeing lots of other odd things with channel sets in 16-bit mode. Sometimes I'd get ranges like 0 to -1 for a set and others I get overlapping sets.

In my head (which is probably wrong) the desk stores all values as 24-bit numbers, perhaps there is a bad conversion somewhere. Math in the calculator still seems broken so I wonder if it's related.

• to my understanding:

encoder resolution Dec8 on a 16bit channel, is expected to increment both coarse and fine on each encoder-click:

if it didn't simultaneously adjust the finechannel it would either be impossible to reach minimum (0/0) or impossible to reach maximum (255/255)

from the minimum value to the maximum value there are 255 coarse steps

from the minimum value to the maximum value there are 255 fine steps

to increment from minimum to maximum with 255 even steps, you need to increment both coarse and fine at the same time

----

In the current version, calling a Channelset via the Calculator is limited by the resolution of the calculator, which defaults to the resolution of the Encoderbar.

If the resolution of the Calculator is based on integer values with a lower resolution than the actual resolution, accurate recall of the channelset may not be possible.

Plausible workarounds until this limitation is fixed, and channelsets in the calculator bypasses its resolution-settings:

• Use an Encoder-resolution that is not Integer based (e.g. percent) - remember your sheets could still have the desired resolution
• Use an integer-based Encoder-resolution that is equal or higher than the actual resolution, - remember your sheets could still have the desired resolution
• Change resolution inside the Calculator before calling the Channelset
• Call the Channelset via other means than the Calculator (e.g. Smart-Window)
• Thanks for explaining Andreas, until this limitation is fixed I will use workarounds

• Other codes less commonly used are variations on the binary code such as the excess-3 or Gray code, alluded to previously, sometimes used in shaft encoders, and modified, as noted where the ambiguity problem arises.