[quote=“Mika, post:320, topic:43”]One of the options we are thinking is to have the FFB effects side and general class structure in an open repository with specific non-commercial (excluding Granite Devices) licensing, so talented people could make filtering and other similar stuff that we would then add to the official builds. I think more complex stuff, such as "hey, this is how you interface with (some device) using SPI, with ST Microelectronics -provided HAL driver, is going to have to be developed as a demo app from the ground up by some other developer, and then we would port that code to SimuCUBE. Any serious hardware development is definitively going to need a working build environment, knowledge on how the HAL is used, and some debugging device such as Segger J-Link.
[/quote]
Wouldn’t that rule out that people can port the new code over to Argon or IONICUBE?
I think they were hoping that there might be some community-driven port to get those to the same state as SimuCUBE will be.
IoniCUBE build would probably be possible, but it requires the additional custom RS485 chip between IoniCUBE and the discovery board. I don’t think we would invest the time to take this into any account in the configuration software, for example. Would be a totally diy job.
For Argon, there wasn’t ever a plan.
So far what we have found is that all the decent simulators use just real torque based effects either via the constantforce effect or via periodic sine effect, with magnitude 0 and offset from zero giving the torque.
This is the real way to do it, as the steering column torque is being calculated in the simulators.
All other effects are canned and artificial, but we will do at least some of those in the future.
Mika,
Now that our Australian crash test driver has verified the update are you releasing today?
I’m just making final adjustments, so lets see. 
It has been released.
You the man!
Any new special instructions?
instructions should be in the manual, see the link to google drive.
SimuCUBE bootloader is quite robust; it will not boot a corrupt firmware (it rechecks the code checksum every time). If there are issues in any of this, please tell about them in the bug report thread.
I know, that’s why I wrote “community-driven”. After all there are some people who did the original OSW and do have some experience with coding such stuff.
I think they might have a chance to make that happen.
But anyway, let’s all just focus on SimuCUBE for the moment. 
All the new encoder support, the reconstruction filter, etc. are in Ioni firmware, and there are no plans to release that as open source. The added value of porting this to Argon builds would be quite small.
is there some way to see the revision history?
it would be easier to review the documentation if we could see what changed from the previous versions.
In this version, there are no changes, thats why the release notes text was so short. Other than some testing for the magical “values change by one” issue, I did some additional stuff to ensure that…
I will start a proper release history page somewhere, starting from the first public beta.
Wow this feels AWESOME!!!
I previously did some testing on the bench with v1 of the beta.
Today I drove with the newest version in iRacing and I am very impressed!
Well done Mika and gang!!
Question:
The center frequency setting in the utility is that the same frequency/function we were setting in MMOS setup?
I was drifting the Skippy at Road Atlanta!!
I had to stop for a few minutes because I could not stop laughing!!!
No, its the peaking and notch filter’s center frequency. That is a filter that is on Ioni.
The one that we set with MMOS was the frequency of the PWM/DIr signal that the STM processor used to talk to Ioni. This firmware does not use PWM/DIR signals to talk to Ioni, this uses the RS485 SimpleMotion bus.
Can’t wait for that Mika
Thanks
Could you also link me to an explination of how the reconstruction filter is supposed to work?
I really do not feel a drastic difference between 1 and 4.
Interesting that with tuning the TBW really high that the AKM52G no longer has all of the metallic sounds coming from it.
See @Tero’s post earlier in the thread:
The setting value (1-10) is used to get internally a set of 4 values to the filter. Setting value 5 is the one we implemented first and the rest are just guesses to have more smooth (>5) or more jagged signal (<5). The end result is by no means linear, and we will improve the filter in the future too.