SimuCUBE Open Source Firmware Development Update Thread

There should be a little bit more simple demo app, also by ST Microelectronics, that updates the firmware via the DFU mode, but I don’t know how ready it is for distribution to actual users.

So, no, we won’t include anything like that at the moment.

we need a very short, straight to the point, “getting started” section with most of the interesting (to us) technical details left out completely.

in my experience, users have a finite amount of time for “instructions”. especially for very exciting, very important additions to their hobbies.

they have the best intentions of reading the whole manual, but once it starts taking “too long”, they start skipping and skimming, looking for the important parts. often, they skim right to the end of the doc and close it altogether.

and that is when the trouble starts. for everyone.

My thoughts on this?

:slight_smile:

Although if it is perfect… is it then an open BETA ??? just semantics lol but put BETA on it an d there hopefully is an expectation that things May not be perfect…

But really things are more perfect than not which is really good…

@sv1 - I will look into this but it is sort of there in the Boot Loader / Install instructions because after it is installed it pretty much does step people through the process of getting it up and running with the Motor Config Wizard… Any changes with this will probably come AFTER the next closed release as there will be sections updated in the guide for Profiles… I will try of course to update all of that as soon as possible after the release of the next Beta.

@Mika - Not sure you can ever get people to “Read” instructions… Even with the Guide on iRacing for Granity and MMOS I still end up getting the simple questions asked all the time. Sometimes I answer others I just say follow the link and read (depends on my mood).

@phillip.vanrensburg - LOL

I think as far as manual/guides it is best to include detailed step by step instructions.

This should be done in the least amount of words possible. If it is as long as war and peace nobody will read it.

When explaining setting TBW Etc, say it makes the car feel xyz.

Brion did a very nice job on the Ioni guide. It would be even better if there was an example as to how a setting effects the feel of the car.

It is Beta until Mika/ Tero says it is not. :wink:

That is true… I was actually just joking around a little there… Mika seems to be a perfectionist which is good for a task like this…

I think I have some examples of how the feel gets changed in there for the filtering in the Firmware Guide. It is very difficult to explain the filters which is why it gets a little more wordy than just do this. Going too far will have different effects than too little, even right now I am doing testing to figure out the differences with the Firmware as the filters take to the system differently with the Reconstruction filter than how they take to the system with MMOS… The Reconstruction Filter at different levels is also imparting some aspects of feel that cannot be re-created through the after input filtering (or at least I have not found the right combination of % to do so)… So for the most part the best that can be done is to have the description of what the filter does and then have someone play to find their best setting. Of course we can try to set-up some good baseline starting parameters. Which maybe could be put in a Quickstart sort of section.

I will at minimum based on what you said reformat some aspects so that in the Outline the Filtering and what each filter does in more readily linked, right now it is just lumped under the IONI Drive Servo Filtering, which, now that you mention it does make it rather hard to find in the guide since it is not clearly labeled…

Brion I hope you know I was not complaining.
I was just adding my 2 cents worth.
So many times I have been asked how xyz setting will make the car feel and I can not find the words.
What is really funny is the comments like "it feels like I am driving a coffee bean grinder"
Personally I have never driven with a coffee bean grinder so I can not relate! LOL

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.

Thanks for the tips!

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.

I bet his temp is only 60-75 deg C. Mine get as hot as that running it hard for a few hours,

It’s ok to run these there though, they’re designed to run 24/7 in industrial environment…

Hey Beano,

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! :slight_smile:

4 Likes

Good news!

Does Tero have a list of supported encoders yet?

I am getting many questions. At this point I am telling people to wait to purchase unless someone else has proven that it works.

Yes, there is the list: http://granitedevices.com/wiki/Using_BiSS_encoder

There’s similar list for SSI encoders too. I hope this helps!

Thanks Tero!
That is perfect. :wink:

Announcement

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.

3 Likes