If you are one of the ones we gave permission for Beano to email the firmware, then unfortunately we haven’t had the time to add you to the group as only the forum admin (Tero) can do it.
I will remind him to do it when we happen to be at the office at the same time 
No worries, thx a lot Mika.
Yes Mika, Ben and George from DSR are the ones I’ve discussed.
Thanx for that!
Cheers,
Beano
OK, end of weekend update:
Version 0.5.0 quality was low, quite serious bug that one. I’m going to implement a “safe test mode” which is active at init, and will divide motor torque by 10, until user specifically selects to use full power and saves settings manually.
Next week, I shall be checking that the bootloader has some error checking and that it does what it is supposed to do. This means that I need to program the UI quite a bit to detect old firmware version and to then give the user option to either update firmware or to close the configuration tool. This, of course, requires quite a bit of testing.
Also, we have internally recognized a need to have button inputs working sooner than later. Sorry for overriding the vote! I will concentrate on that next, while also trying to improve the bumpstop effect.
The firmware actually already has a method to “give” and “get” 256 different profiles. I think I will need to add a field for Profile Name, and then implement all that to the Configuration Tool.
I think the next beta with actual new features will be the somewhere near the middle of the month. For the current 0.5.x series, I will release new fixes / test builds, depending on what the users say about the momentary loss-of-feedback or lost center point with different encoders.
@Mika: Thanx for the update.
Yes, fully concur on the way forward, highest priority items should be the FFB comms issue, that needs to be resolved as a matter of priority.
After that Bootloader and buttons. Other new features can be done as necessary, but we should also bear in mind, main idea is to provide stable minimalist OS FW and community should be able to contribute then. Otherwise it will be never-ending process for you.
Bumpstops as they are now are very good and better than ever before, so again, idea is to have good working solution, people can then spent energy on adjusting via the code if they so wish.
There are few small issues remaining, once that is done, we’re ready to go
Just anyway my view on things, those nice new things can come at leisurely pace after main features are working 100%
Have a good one, thank you for all your time and energy on this!!
Cheers,
Beano
You and some other people that Beano suggested have now been added to the beta testing group.
in the old days, previous to the open source firmware, i was able to run granity and utilize the testing tab and capture data, to see graphs of the power and amps being sent to the servo. i used to run this in a separate window while iRacing to see how close i was getting to the MMC limit.
with the new firmware, i can’t run granity at the same time while in a game.
is there some way to capture or log data like this when using the new firmware?
No, not currently possible and quite low priority. Average user won’t ever need this type of data.
The reason is that reading any drive parameters other than the encoder position into the SimuCUBE would take too long. Even if it happened once every second, user would be able to feel it, as torque command would have to be paused…
Things might change with new Ioni firmwares in the future. Meanwhile, the SimuCUBE firmware knows the values it is sending to Ioni, and percentage of the maximum torque could be calculated based on that. For example, averaged over the last second (2500 values). This value could then be sent to the UI, which requests a status packet once a second.
Need to be careful on the calculation time though. Need to leave enough margin for everything.
Then this value could be easily shown in the UI, but plotting it wouldn’t reveal spikes that caused clipping…
Granity has an offline capture mode as well, but I haven’t played with it so I don’t know what type of triggers it supports. See https://granitedevices.com/wiki/Downloading_offline_scope_capture_in_Granity
mostly, i am interested in whether i am clipping or not and whether it was a momentary spike or something longer. the granity graph was just an easy way to see it.
thanks for the explanation.
I would appreciate feedback from the UI when used with “high DPI” displays; those that require custom scaling settings somewhere in Windows settings. Displays with 4K etc… are like this. This includes if the scaling works correctly, and if it does not, is the app still usable or does it break in a way that should be fixed.
Whatsapp sent with screenshots
Great progress with bootloader today. Every needed functionality is implemented now, both on the UI and in the bootloader firmware. Next, testing, followed by more testing, followed by more testers.
Great news, thank you Mika!!
You are a proverbial Workhorse when it comes to this stuff, seemingly never tiring. Much appreciated!!!
Some of you might have noted that @Tero released new official Ioni firmware today. The version is 1.6.0 and the version code format has been tweaked, so that it somewhat resembles the version number. Old type was 1192, and the new one is 10600.
If this new version is installed to the closed beta SimuCUBE firmware, then the SimuCUBE firmware will immediately overwrite it with 1192, so please do not try to do it
The next closed beta will have bootloader and the new Ioni firmware bundled.
Originally posted this in the Bug thread, but it certainly doesn’t belong there. Just a general question:
I know it’s the road least traveled, but has anyone tested compatibility with Project Cars? I doubt anyone one here is in WMD in order to test with the current builds of Pcars2?
Hey Mika, great stuff you are working on! I can’t wait to get my hands on it when do you expect the new beta with more testers and how can I get in the next tester group?
I have access to Project Cars 2 and did a few laps with it.
The basic functions working right out of the box, but I have not yet found the settings where I’m happy with it. (tested only about an hour)
Is that a reflection of PC2 FFB more-so than the FW though?
I see so many conflicting reports of the handling and FFB, I don’t know what to make of it.
Comparing files simucube_firmware_bootloadable.bin and SIMUCUBE_FIRMWARE_BOOTLOADABLE_MEMORYDUMP.BIN
FC: no differences encountered
I read about the bump stop issues that we are having with assetto corsa. When I had the csw v2 I used them fanaled where it is possible to enter the data of the various cars with the relative steering angle that interfaced with the driver and changed the angle directly to them (in the forum there is a file directly with all The corners set). And it was perfect. Can your firmware interface with fanaled to get this?