The Recon Filter Hz is Frequency of update (read)… TBW is a low pass frequency filter so the higher the number the more high frequency signals get processed and not filtered out.
Oh and to bring this sort of back on topic…- I haven’t found any new bugs to report as of yet… Except maybe the accuracy of the Notch filter has gone down a bit as you can’t use x.xx numbers in the Hz only x.x… Maybe I’m just thinking it was this way before I can’t remember though.
The recon filter will update new force values at 2500 Hz rate to the wheel, in time domain. The resulting signal can be almost anything in frequency domain, although almost all of the very high frequency signals (that result from the 60Hz signal being jagged) are missing.
I’m currently implementing the profile management to the user interface. It is very disruptive in the code side, and I would not want to have the public seeing those bugs that are inevitable in this kind of process.
Yep, Mika’s view is correct for this, otherwise he will be inundated with quite a lot of feedback, not all of it necessarily accurate either. So best it be tested in the closed group first before final open beta release.
On a very positive note, have been hammering a variety of cars on iRacing, with zero FW hick-ups. Nada, zilch, zero. Things are looking very good at this point, which is all I can ever ask from fw.
Hello, I’m not sure if this is the right place to ask this as I don’t think this is particularly a bug but I thought I would see if someone could help. I just tried upgrading to Simucube firmware 0.6.3 from firmware 0.5.2 via DfuSeDemo (I used the dipswitch to enter bootloader mode as I did when updating from mmos to 0.5.2). After this update, the Simucube configuration tool no longer recognizes my Simucube despite several power cycles and leaving the unit powered up for a few minutes (I did move the dispatch back). Windows never begins loading new drivers either as it did when updating from mmos to 0.5.2 and “Simucube” is not shown within the list of game controllers like it normally is. I also updated the granity software to version 1.13.0, and from within the granity software I updated to ioni FW 1.6.0 with no change. If I go back to Simucube FW 0.5.2 then the configuration tool recognizes the simicube properly again, but when I go to 0.6.3 the configuration tool still doesn’t recognize the Simucube. I’m not sure what I am missing here but maybe it is something simple that I messed up or missed along the way. Hopefully someone can offer some advise as to what I should check or what I may have done wrong. Thanks for your time guys.
You are missing the important point of the 0.6x versions: Only the bootloader (firmware updater) can be flashed via DFUSeDemo.
Then, you flash the actual application firmware using the 0.6x configuration tool. It allows user to press the Update Firmware button, and tries to find “SimuCUBE in Firmware Upgrade Mode” in the devices. Then it uploads the actual firmware.
This was explained in the user guide.
Also, we changed the USB Vendor ID and Product ID for 0.6.x, so thats why an older configuration tool will not find any SimuCUBE devices when using any 0.6.x and later versions.
Edit:
To add, it is possible that a first distribution of the firmware will have both the bootloader and then-current application in the same DFU file. It is, however, simpler in administration side to just use the already developed method, as the full dfu flashable version would have to be kept up to date for any new migraters.
Thank you again for the help Mika. I did not realize that there was a revised version of the user guid with each update so I was still reading the older version I had originally downloaded. I did notice after reading through it again though where this is explained at the beginning.
I have now used the new configuration tool found along with the FW file and was able to update the FW to the latest version without issue. I had a feeling that I needed to update the Simucube Configuration Tool however I was looking on the forum for a link to the download, I didn’t think to look within the 0.6.3 FW file I had already downloaded.
Now that it is all ready to go I can get back to testing in different games and see what I find.
I had a slight problem with Firmware Updating that I thought was worth reporting both the Simucube and IONI were new out of box latest versions
I used DfuSeDemo to flash the 0.6.3 bootloader then proceeded to upgrade the firmware with the Config Tool, the Simucube updated successfully, the IONI update started as expected so it was left running for a few mins then I restarted
After thr restart the IONI was still in DFU update mode so I switched to IONI USB configuration mode as suggested and opened Granity (latest version) the drive could not be found whatever I tried restarting etc but no luck
I had to recover the IONI by flashing the Simucube with the MMos .dfu file the drive was visible in granity and updated successfully then revert to the 0.6.3 FW
Interesting. I also managed to get the Ioni update to fail, but unfortunately didn’t catch the reason for it that time. I will continue to keep an eye out…
Strange comportment here. After W10 update, after 2-3 min in Iracing, loose FFB and direction. I open conf. tool and “picture” of Wheel is frozen.
After one hour trying something (including “guru” dance…) decide to erase last Windows update. And without nothing else, it’s work fine (run more than one hour without any issue).
Did you ever eared something similar (I didn’t check yet what is Inside this f… update)?
Good to know. My own SimuCUBE at home has been constantly powered on for a month soon, without any reprogramming. I have driven occasionally, and it still works.
I don’t really know if this is worth trying to debug now.