Price of encoder 80 USD. Link is on taobao page in CNY…
Hey Mash,
Ioni can support higher resolution, in fact, I am using 22-bit /4M CPR on my setup, but…there is a challenge to stream all the data back/forth between SimuCUBE and IONI and still ensure we do 100% hit-rate with the FFB data…
Once we go past the 21-bit /2M CPR mark, a few guys have experienced ‘hiccups’ in the FFB feel, almost like micro-stutter, and Mika and Tero has clamped the officially supported resolution on simuCUBE side to 2M CPR…
The 2M limit comed from this:
Ioni gets updated at 2500 Hz. At every update, the amount of change of the wheel position compared to the previous update must fit into signed 16bit integer. The angular speed of the wheel required to surpass this can be calculated. The update rate should be enough as that speed is actually quite crazy high, but still people do see some loss-of-center events at >2M CPR when using high forces on bumby track -
DW12 at Sebring, for example.
We think there are some hickups still in the firmware that may cause the 2500 Hz rate to momentarily dip, causing this. But as these crazy high resolution encoders don’t have any effect to the feedback feel, we decided to put a limitation somewhere. This is, in part, to save us from spending development time early on in something that has 0 effect to feel and that would “benefit” only those that bought the most expensive encoder.
1 Like
We have had exactly 1 interested party contact us to get involved with open source development. That development is hopefully starting soon. What makes you think releasing the code as totally open source would change the number of interested people? What is your view on how we could release the firmware?
Definately interesting.
Ha, thanx for setting me straight, Mika, so it is to do with positional update and fitting new data to integer value.
So perhaps some small timing issue there.
But anyway, no dramas, we know this limitation and can work around it, as you said, no benefit going past 2M CPR anyway.
Cheers,
Beano
Eh, is having 32bit integer going to solve those limits? Is it really necessary to have 16 bit? In terms of cheap good abs encoders - I see 17 bit which is not a lot and 23 bit.
Mika, I believe that everybody afraid that eventually you won’t have enough time to keep pushing it like it was at the beginning of Simucube time. Having it OSS would just allow to a) increase speed of feature development b) calm people that support won’t become stall. You are free to use some GPL license to make sure competition won’t release 30$ Simucube with embedded Ioni, but you understand - those who really want to make a clone they can decompile firmware or just make exact hardware clone. What stops that is a community that is dedicated to the specific brand and OSS certainly helps to that. Easy dev-env, good documentation, set of unit tests and people would be submitting their patches with new features eventually significantly overcoming internal resources.
Btw, I believe that main advantage of abs encoder support here would be no TBW limit and probably smoother feel.
This limit comes from the SimpleMotionV2 API, and changing that just for this SimuCUBE usage case does not bring enough benefits to invest our time to do that, as the feel would not improve. Also, changing the API could have wide-ranging effects for our other customers.
- Having it OSS would just allow to a) increase speed of feature development
If there is someone who wanted to to implement support for device X or feature Y using STM32 HAL API, we are listening. So far, even while advertising this opportunity, we haven’t gotten any contacts for the device side of things.
- b) calm people that support won’t become stall.
DirectInput development will become stalled as that API does not get any changes any more, and hasn’t gotten since many years.
- You are free to use some GPL license to make sure competition won’t release 30$ Simucube with embedded Ioni, but you understand - those who really want to make a clone they can decompile firmware or just make exact hardware clone.
We don’t want to make it easy for the chinese. Their current copy uses different motor control technology, but we don’t want to give the DirectInput device side either.
2 Likes
So you’re confident that sincos is a placebo? Otherwise why do you say that feel would not improve?
As about OSS - it’s up to you, certainly. My own brand forged by chinese for many years. But eventually it doesn’t really matter - if you’re stronger, you have loyal crowd - it beats low cost clones. If it was OSS - I would check code and see if I can implement support for abs encoder and high resolutions myself. When I don’t even see it - I have no idea and so based on what you say it’s probably won’t be done.
And I’m absolutely sure that competitor of Simucube is not some Chinese clone, but much larger guys like Fanatec. And how are you going to beat them? They certainly more than capable to do more attractive plug and play product. And directdrive is not a problem for them. And moreover - they have gamedevs support. Simucube opens up possibility for all those kits of different types from many shops - cheap systems, expensive, professional sims, public consoles. And they need platform that has community, features, which is future proof. And those guys can invest their time to do more features. This is ecosystem. No copycats can do such things. And Fanatec won’t play this game. So it opens up an opportunity. And ecosystem needs seeding and support. Convenient OSS is important here or large dev team with API, plugins and so on. And even then - people would be concerned that one day you will ruin their business by changing your mind or not paying attention to the project anymore.
It would be sad to see if big guys would win again while you’re afraid of some Chinese…
The encoder reading and interfaces are in the IONI source code, which for sure won’t be opened up at all.
SinCos is not placebo, but its additional benefits after 1M CPR and certainly after 2M CPR are very, very questionable, equally to zero. Keep in mind that directinput is 16bits over whole bumbstop-bumbstop range.
Additional benefit is ability to use this product from the market which right now is not going to work at all even if SSI would be implemented in Ioni. It’s btw would be great if Ioni had some kind of OSS plugin library for more feedback support.
And advantages of abs digital encoder vs sincos are listed above - I don’t know if you see anything wrong in what I’ve stated. Especially ability to use high TBW.
I just don’t see affordable abs encoder that is around 20-21 bit. I see 13, 17, 23.
I’m well aware that directinput positioning is limited. But it’s more about smoothness and reliability of motion itself.
Yes, but 2M CPR is smooth enough for a human would be able to notice the difference after that. However, when using a very, very high quality servo such as those Lenzes that are built for paper presses etc, one could perhaps be able to find a difference… when using a torque measurement device, in laboratory conditions.
Mika, 2M CPR is smooth, but it’s prone to EMI glitches and not solving crosstalk issue at all.
Mige now have two encoders available, 2048 Sincos and 21Bit BISS-C
I have the SinCos on order if anybody wants one, I have also ordered a few BISS-C to test
I would upload the datasheets if could but it doesn’t allow PDF’s
1 Like
I guess I missed 21 bit BISS-C. What’s the model name?
Baumer EFL360 BISS-C
Which motor is it on? EFL360 is for 6mm shafts… I have a feeling it should be 580 for Mige.