No I have been trying to think of ways of possibly making it easier, it is just hard to explain those thingsā¦ But your comment did make me look at the hierarchy which for the filters is not currently there and should be there for easier locating in the guide as those will be the most used items, second only to the profiles,
Anyway if you do get the Coffee Bean Grinder with MMOS it is TBW (lower) and Overall Filter (higher though is suggest no more than 5) that diminishes it. the overall filter tends to latency wise work better than TBW. Last resort Friction.
Dampening wonāt get rid of it because the 60Hz input signal introduces some of that (turn off the Reconstruction filter and you may get the idea) and Dampening that signal seems to be sort of hit hand miss in that the Drive I donāt think always knows what it is trying to Dampenā¦ I have found Dampening is MUCH more predictable with the reconstruction filter (as are the other filters as well).
feel also changes considerably track to trackā¦ Try driving the 488GTE with the default set-up (if you have it) on say Watkins Glen and then go drive it on Mount Panorama and it is seriously different so much so that you start to wonder if something is wrong or is it REALLY that much different. For those that donāt want to tryā¦ Mount Panorama is feels lighter in static forces BUT it is also much. much bumpier which causes Jolts through the steering. especially the kink coming down the hill It lightens up the front end and there are a couple of jolts that feel like the wheel will be removed from your handsā¦ as well some of the uphill twists the steering gets light and quick reacting and you wonder if it will throw you in the wallā¦
Mount Panorama I am finding is a good place to test inertia settings as inertia helps you turn the wheel in most cases and if you have it too high and you are running fast around Bathurst you WILL mis-judge and turn yourself into the wall at some point as you will hit a bump overturn the wheel and when you land, in the wall you go.
I think I will buy the Ferrari as a few guys I have setup with wheels have asked for help tuning.
Have you heard anyone having problems with AKM motors getting hot?
I have a guy who is running the AKM52 exact same settings as me and his motor is getting really hot mine is cool.
His motor is buried in an IndyCar tub, but he says he has a fan bringing air in.
I asked him to buy a thermometer to measure the temp so we have numbers to work with.
Hmm havenāt heard of that, Is his resistance/Inductance set via Granityā¦ The only other thing I can think of is that he is just running it hardā¦ i.e. using a DW12 with upper power settingsā¦ The heat though should not affect too much (other than make him feel like he is actually in the car) as the servos generally can run quite hot without having issueā¦ I know when I was running the Small Mige for a while it would run WAY hotter than my Large mainly due to me running it harder with the same specific output.
Not sure of the temp yet, but he says it gets very warm.
I just started driving the AKM52 a few weeks ago so I am not an expert yet.
I will say that motor feels much better using Simucube and Mikaās new firmware than I remember using it with an Argon.
I can now really tell that the motor is superior to the Mige.
Justin I think is one of your teamates? Good friend to Ben.
He ordered a thermometer today.
@brion
Yes his resistance and inductance is set via Granity.
Yes he pushes very hard and is running the endurance races so he is running long stretches.
As I said the motor is up inside an Indycar tub I do not think it gets alot of air across it. Once we have actual numbers to compare it will be better.
A new Ioni firmware version is now out. According to @Tero it should fix some issues with BiSS encoders.
Unfortunately the SimuCUBE firmware will insist on installing the bundled 10060 version every time, so, I will have to hurry up to get the next closed beta (with profile management system) out sooner! But we are not too far!
We have seen, that customers are already acquiring encoders in anticipation of the new, highly anticipated SimuCUBE firmware. Higher CPR values than the commonly used 20000 or 40000 will give smoother feeling as the position is tracked more accurately on the servo drive. This is true even as though the interface to the PC (game) is 16bit, i.e having values of 0-65535 over the full lock-to-lock angle. The improvements are even more noticeable in high-end servos such as AKM or Lenze.
We have gotten some inquiries, both directly and via some resellers, about some customers trying to find very, very high resolution encoders. We feel, that after some point, there will be no discernible improvement when used in SimuCUBE application. Also, there is a CPR limit after which the SimuCUBE firmware can lose the tracking of actual encoder position. This a limitation in the way the encoder is read to the firmware via SimpleMotionV2 bus combined with the 2500 Hz force update rate we chose to use. Loss-of-tracking could happen in very fast bumps (or crashes) especially if hard forces are used. Also, if there ever was a filter or other calculation that prevented one or more of the 2500Hz updates to happen, then loss-of-track could occur more often. To overcome the limitation, some not-insignificant changes to the firmware (both Ioni and SimuCUBE) would have to be made, with very, very small or zero benefit.
We have therefore decided, that CPR value of ~2 million (21 bits) will be the highest that we will officially support. Encoders and settings giving higher CPR than that could work, but we wonāt support any problems that might arise. Our website/wiki will be updated to reflect this, at the time of the public beta release if not sooner.
Iām just now having a hard look at the current code, and it seems that it already checks whether the version of Ioni Firmware is smaller than required instead of exactly the correct version. So, flashing the latest Ioni firmware should already work without SimuCUBE trying to overwrite it.
Any idea what sort of timescale we are looking at for public release, is it months or weeks?
I am speaking to one of my customers about delaying quite a large install but we do have a deadline
Public beta will happen when its ready. I didnāt have time this week that I though I had, so I still have to test the profile management; and for research purposes, Iāve implemented a simple export/import for analog settings data, as setting those values all over again after enough of a step in firmware version number is not fun.
I did a code review today, and the profile management should work.
Public beta release timescale is week(s), and public stable āproductionā release might be weeks to 1-2 months, depending on what we eventually will be calling the stable release. At least we will have to implement some effects that are used in games, such as game-controlled damping.
GUI will remain closed-source. We will be able to change the logo for customers, when we get closer to stable version.
One idea could be that the Configuration Tool would look for a certain PNG file in the installation folder, and if found, show it instead of our supplied logo. Would this work for branding purposes?
This data is not servo-specific, itās only sim-specific, right?
What data would you need exactly?
Ok, I guess most people wonāt need that many.
Actually this gave me an idea, which is something I like about the Steam Controller:
it would be nice if there was a way to exchange profiles for games.
For most proper sims, this doesnāt matter too much as itās normally ok to just do the most basic settings and youāre good to go.
However, many vintage racing games have some kind of āspecialā FFB in that they do weird stuff.
e.g. I ran Test Drive Unlimited recently and while it felt quite good on my SimuCUBE, I think it could be improved with changing a few settings.
I just need to find the time to play with the settings for a bit and find the perfect setup.
However, when I did that, others should be able to profit from it, so they donāt need to do this again.
Hence uploading the profile would be a nice feature.
(Of course one can always upload it via a forum like this.)
Edit: bonus points if there is a rating function for downloaded profiles.
The needed data is text data, that the firmware outputs to hardware serial port on simucube, and for ffb data output, I would need to compile a special build. It doesnāt make much sense for you guys to purchase suitable USB-TTL serial adapters, as having/getting the data is about 1% of the time needed, and I would need to spend extra time to compile a version that outputted sensible data. In addition, when the data is outputted to USB port, the FFB can be unusable as printf() printing can take so much time that communication with Ioni can fault too often to make the system usable as a ffb steering wheel.
Profile export and import is coming, but not at the first version that has profile management. Although I did yesterday the analog configuration export/import. If it works as I expect, then I think that is a good base to build similar functionality for (more complex) profile settings.
