Adding that every 0.0001s the encoder position is read into an unsigned 16 bit value (0-65535) which is then on the firmware wrapped to 32bit counter. This is a limitation of the software API that we use to communicate with Ioni.
Reliability of this is dependendent on the 16bit value never going around between updates. 65535/4194304 * 360 = 5.62.
Close enough to your reported values, then…
Mika, can I lower the 22bit value in Granity to something lower for the time being?
Tero would be able to answer that. I haven’t configured BiSS via Granity.
I also informed him about this bug/limitation. Its an incentive to read the encoder at 32 bits, but I don’t know if it will be possible.
I consulted Tero about this.
You can just decrease the bit accuracy in Granity, it just drops one bit of accuracy, so its ~2M. You will have to run the wizard again too. I think it won’t make any difference to feel at this high levels of CPR.
Only 2 million CPR 
Sorry, not 100% sure what to change the current 22bit setting to? 21bit?
Or just experiment reducing until the error goes away I would guess or around 2 million in the UI.
Yep, when you remove one bit, its the same as division by 2.
We have also other fixes in mind, for example, Ioni could give “saturated” values for the 16 bit value so that when we read it, it will have never overflowed. But things like that are not on the top of the list for fixes. Can’t we agree that 2 million CPR is enough? 
It will be also valuable to know if it happens for you with 2M CPR, or whether you would need to go as low as 1M CPR. But, as we all know, even that is quite high compared to typical 20000.
Hello Mika,
Will be testing it tonight when I get home.
Really I thought that the 10K 40000 PPR was more than great. But you can actually feel the difference on the high resolution BiSS encoder.
Almost impossible to find absolute centre when I was setting my index mark as close to zero in Granity testing window. 6000ppr is about as close as I could get.