Tero’s picture was with the setting at 5. Lower settings have significantly less oveshoot, where as 9-10 are really bad and the spike has >20ms lag also.
We are doing other types of filters too, sometime in the future.
Different filter algorithms for signal directions might be difficult to get working reliably.
Important thing to note is that filter types in your pictures 2 and 3 already have unwanted general lag. We don’t want that 
And based on the general feedback from current filter, the small spike/overshoot doesn’t seem to matter too much. I think that on lower settings 1-4,much of it gets filtered by wheel/servo naturally.
[quote=“bsohn, post:194, topic:43”]
Add some dampening if you haven’t that will solve the oscillations with the skippy. a small amount probably 1-2% should completely get rid of the oscillation at lower reconstruction filter settings.[/quote]
I am running dampening at 2%, friction and inertia at 1% each, in both cases (recon filter enabled or disabled)
i can increase the dampening values (and yes, i know that sitting in the pits is not the focus), but the reason i posted the “when sitting in the skippy in the pits, the reconstruction filter produces oscillations. if i turn the reconstruction filter off, the oscillations stop” feedback, was to point out that the oscillations only occur when the reconstruction filter is enabled. when it’s off, i have no oscillations.
i was thinking that behavior might be interesting or useful information.
Its useful information for sure. I wonder if it is a combination of that high-end servo and good encoder, or what does it…
New poll about how to present value for endstop angle (separate from steering angle).
Still, not sure to handle how to handle user changing steering angle suddenly from 900 to 10, for example. If endstops are enabled, this could result in rather wild spinning wheel. So, need to check for wide range of user hardware damaging possibilities for this, or just to disable changing steering angle if e-stop is not pressed.
Suggestions?
I’d suggest a function to automatically disable endstops as soon as there is any change to the wheel angle
Like a reset
Normally it wouldn’t make any sense to change the wheel angle and not change the end stops accordingly
The problem with this is that users requested auto-applying settings, so if endstop just gets disabled (its very doable), the moment user checks the enable endstops again, auto-apply would again enable them. I could implement some default “gentle” settings to endstop to be applied whenever user enables them via the checkbox, but this would result in user losing the previous settings.
But even when auto applying settings ( which only makes sense if you change sim and car), wouldn’t it be possible to first reset the endstops, then change the angle and then reapply endstops?
Automaticity has to be through a setting file, so it should be possible to just read it out on the fly an apply settings step-by-step ?
Yeah, but must somehow prevent applying settings that would cause wheel to fly towards center in unexpected ways.
I might even take auto-applying settings out for now, because of safety.
What about auto Apply only works with in 10 degrees of center.
What is the advantage of auto-apply of changed settings if you can just save the settings by just clicking one button?
For me, auto-applying settings is not a necessity.
It is useful but it is also useful to see if there is a reasonable fix as … For me I have dampening 5.5% with nothing else and TBW Unlimited and no oscillations up to 5 haven’t tried anything else though higher yet. I posted the comment because there are some inherent factors that cause oscillations so not all can be corrected out as easily as with a filter. One of the reasons why it shows up with the reconstruction filter and not the normal filter off is that filter off is sending the FFB signal into the SimuCUBE system at 60hz where the reconstruction filter takes that signal filters it to be more accurate to intended and then updates it to the system at a far greater number (I’m not sure of the exact but 2000Hz or so) with this any small movement off position can start the feedback oscillation loop.
This was on my mind too. Easy to implement as well… But need to carefully set all the parameters so that 10 degrees is enough, by some margin.
There used to be, in alpha testing, a separate apply -button.
One must remember that pressing save after every setting change will wear out the flash memory quite fast. STM32 series microcontroller flash memory is certified for minimum of 10 000 write cycles, so it should be more than enough, but frequent writes should still be avoided.
Mika and I had a bunch of discussions about the Auto apply… By having the auto apply it will set the SimuCUBE to the settings that you change within a short time after changing them, this lets you quickly play with settings and alter them going into and out of the sim. When you make a change these settings are Only stored in the current memory and are not permanently applied to the Flash on the SimuCUBE so as not to wear out the FLASH on the device. This is why the flashing Click save to make settings permanent come up to remind you to save the settings if you like them as if you don’t they will NOT remain after you power down.
The apply was deleted and Auto-Apply put into place as the effect would be the same in that if you applied the settings but forgot to save to the SimuCUBE when powered down you would lose the settings anyway. Given that most people when they want to make a change want to immediately see its effect, having the auto apply makes sense in that you could forget to hit the apply before re-entering the game/sim making the change not take effect when you thought it should. It basically does the work of temporarily apply the settings for you so you don’t have to remember to hit the apply button every time.
If you don’t like any of the settings changes you have done you can revert to the last saved state via the Load form SimuCUBE…
If you have suggestions to make this easier please share.
So to answer Jplays question… see above… as those are the reasons why Auto-Apply was put in place… Basically if you make no changes nothing will ever be auto-applied.
Ah thanks for the reply.
I was not aware of the limit of the flash memory.
Is there no possibility to save the settings in to the computers drive when you close the application or power down SimuCUBE and then when you turn on the device again, it would apply the settings from the drive and have the flash memory to work as a backup memory?
I wonder how it works for example with Fanatec Clubsport pedals when you do changes to the controller controlling the inputs of pedals? Does it save the values to the pedals memory or in to drive where it loads them up when pedals get connected?
Complex things like this would be possible if we wrote a dedicated device driver. Currently, and for the foreseeable future, we are trying to manage with the possibilities of the default Microsoft USB HID driver.
Personally I am not sure on that but I think it would require a system driver, which the SimuCube doesn’t have where I believe the Fanatec does have a driver level system in place… To load from a file it would require loading the configuration tool at startup… Where right now the SimuCube just uses what is in flash and doesn’t require anything to be run prior to operation. Might be something that could be done in the future but I am not sure if it is in the plan.