Param 906 will be initialized with absolute reading in the next FW. It’s been already done, and if you’re curious, grab the following development snapshot FW that is V1.7.1 + above change = V1.7.44.
I hope this helps!
ioni_fw_10744.gdf (101.4 KB)
1 Like
Is that possible, that we can generate a “lag” for SimuCUBE. I know, that lags be things, that we don’t want. But with my wheel, i see, why another driver loos the cars because the “gaming-wheels” has big lags. If i can set a synthetic lag, i can test that or show another people, what are the difference between gaming and DD-wheels. With TRF1 at 100, TRA1 at 0.33A, max Force 18,333% and 30 - 40ms outputlag, we can simulate a thrustmaster T500RS.
When its open (source), why not.
Hello Tero,
are now the right time for that feature, please?
Most likely such features are going to be implemented to SimuCUBE firmware, although basicly we will aim at reducing lag.
A small thing, that should enable more SSI encoders to be used right away: position readout offset. Instead of starting position readout from bit 0, definable number of bits (1, 2 or more) that effectively offsets the start of SSI binary message. The end of the encoder position value (least significant bit) is definable already by FBST “Single turn bits” value. This would allow somewhat universal support for different SSI encoders.
To illustrate it - first 2 bits to be ignored, marked with red:
https://drive.google.com/open?id=1EB31XFSpEhzBXC0VEOhhFnL-nXcMzCEC
That’s definitely doable. Do you know encoders where it would be needed? I haven’t found any that would require discarding first bits.
Hi Mika,
when you say reduce lag, is this ffb lag, or input lag?
And what about the new FastUpdateCycle in the ioni firmware, is that anything to do with it?
Tero, have you seen my thread
Do you know of any changes between 1.7.1 & 1.7.2 that would cause any differences like this?
Cheers
Of course both.
It has only to do with support of max. 30-bit encoder resolution and absolute encoders.
The Zettlex encoders are my prime example 
but this kind of offset would universally allow almost any variation of SSI protocol to be used right away, as long sequential position data exists (cases with special bit between multiturn and position data, leading zeros etc).
Ah indeed, those are the odd encoders
But we’re planning some changes in serial encoder support to make it more complete. Your idea fits well in the goals. I’ll write a note to our dev team to give it serious consideration.
1 Like
That is nice to hear, thank you! Can gladly test it out when time comes :).
1 Like
Good to know that! Is there some urgent need for that? It might be easy enough to hard-code some bit skipping in custom firmware just for you if needed.
That is really generous offer! You have pretty much THE best support there can be for Granite Devices products, I have to say :). I did set up quick test with INC-4-100-211001-SSI2-RFC6-5-AN I have at hand, this is 21 bit resolution encoder, using 22 bit position sequence, the most significant bit (first red bit from left on the previous bit skip picture) always 0.
Tested with:
Serial encoder type [FBS]: SSI
Single turn bits [FBST]: 18
Multi turn bits [FBMT]: 0
After initialization random movements.
Tested with:
Serial encoder type [FBS]: SSI
Single turn bits [FBST]: works up to 21 bit
Multi turn bits [FBMT]: 1
My temporary setup instability and inductive encoder peculiarity allows to confirm working with motor up to 18…19 bit at the moment. Just angular readout works up to 21 bit, so apparently the multiturn bit can be substituted as bit skip in this specific case as the first bit is always 0. So Zettlex SSI2 version is working already…
Datasheet for the all the Zettlex SSI protocol variations can be found here:
(page 33).
1 Like
Thanks for testing! I confirm that “multiturn bits” parameter can be used to skip leading bits of data without significant side effects. Current firmware uses multiturn data only in one situation: when [HAP] (apply absolute feedback device reading) is enabled in homing. So if that’s disabled, then multiturn bits are ignored and can be used for skipping leading bits.
Tested and can confirm Zettlex BISS-C protocol encoder INC-3-150-221001-BIS3-RFC6-5-AN working with IONI (firmware 1.7.11). That is despite the encoder BISS-C clock specification rating of max 2MHz (IONI BISS-C clock is 5MHz). Tested encoder data output seems to be ok up to 7MHz clock rate.
Still - as I see the IONI firmware SSI clock is at 2MHz and the lead in part of the BISS-C clock sequence is already 2MHz, it may be reasonable to have possibility to have few user selectable BISS serial encoder clock rates (might also help users with long encoder cables).
Thanks for feedback! Glad to hear it works properly.
I have impression that the Biss-C requires encoders to support 10 MHz clock rate. If that’s true then 5Mhz as hard coded default should be safe. However, we keep in mind your idea for future upgrades.
1 Like
When are the release of “TBD, 2021 1.0.31” planed, please?
We have often problems with Bumpstops.
And maybe that are the fix:
Bumbstops
- Changed bumpstops to avoid issue where the bumpstop force could be overcome by game-generated FFB in some cases.
Essentially when it is ready. There are a few things done in IONI firmware also, that need testing and verification before deployment to Simucube users automatically.
1 Like
Those that want to be involved, the IONI firmware is already available and can be updated via Granity.
