New thread!
With exciting news to come.
4 Likes
We have pushed the latest code to the open source repository as well.
From time to time, there has been some interest in some developers to our open source code, and some of them have developed custom features for their own systems.
Plans for open source:
We want to revive the open source project. Here is a list of tasks that we are planning for future, but we need to get these done sooner or later.
-
Here at Granite Devices, we have moved on to more predictable and stable cmake -based build system based on a commercial IDE. For the opensource project, perhaps continuing to use the ST -supplied IDE is better, as it has all the tools bundled in so there is no need to maintain a large software stack for building stuff. ST Microelectronics has released STMCubeIDE, which has replaced Atollic TrueStudio which this project was using previously. We need someone to convert the project to latest IDE.
-
There is 3rd-party code available that seems to have a stable running USB stack without much problems like the original ST HAL stack we were using. We are in process of porting that to our firmware, and at that point (if it gets into release firmware) we will also open-source that.
-
There is clearly a need to simplify / cleanup the code. Some of it has been done already at our internal repositories, but we can’t release those as they include too much proprietary Simucube 2 stuff in them.
-
Code runs in a state machine and a single thread. We are currently planning on a rather large rewrite that would make the wireless wheel task, simplemotion/servo drive communication, FFB processing into separate threads, and to run those tasks in a RTOS. Possible we will use FreeRTOS.
Bottom line:
All-in-all, the firmware could be used in its current state to build / debug / add features to the hardware. Just add tasks to the HandleHidReports() function, which is more like a RunTasks() function anyway.
We are committed now to keeping the development for Simucube 1 as open as we can, but if there is no interest from almost nobody, then we probably will not continue open-source development after that. Having some code open and some not, and then also a lot of hardware specific code, just takes a lot of time and resources from other development.
10 Likes
sounds exciting Mika!
wish I was technical enough to help, but alas this is not my forte.
hopefully some skilled people in the community have the time to help make the SC1 software a growing and evolving thing.
that said, if what we have is as good as it gets then I’m sure we will all be just fine with that too.
there’s much to be said about things just working.
RF2 tested;
Placebo effect ??
I feel everything much better
Thank you !!
I feel everything better too (Richard Burns Rally). I don’t know how is it possible. I’m driving every day RBR and I’m sure 100%. This is not placebo… Thank you Mika, you are good man! You make us happy… I wish to help somehow but I’m only virtual rally driver 
1 Like
Just tried new firmware and everything works great for me. Thanks!
1 Like
Mika, Thanks for your work.
I tried also the new firmware and the centering issue seems to be solved.
2 Likes
I am onboard, too. It will be a pleasure to help to improve SC1.
Works perfect en feels great!
Love it was not sure on settings so I used Simucube 2 ones posted on here as a base but I only use 50-60% max on the servo. Lowered most of the settings a bit feels great certainly better in all games I tried. D Rally 2, RF2, ACC, P Cars 2 Works perfect thanks 
We have found a bug that affects battery consumption for a limited number of wireless wheels. Fix will be out today…
Also, the same bug was in Simucube 2 2020.4 so will need to get the firmware out for that as well.
Holiday looms tomorrow! 
5 Likes
Hey guys was wondering if anyone ran into this issue before. I kinda just started noticing it but am having issues with my estop. When I press the estop in it doesn’t cut the motor instantly like it used to. It takes 3-4 seconds and I have to move the wheel left to right before it finally kicks in. It’s as if it’s stuck or non responsive for those few seconds.
Is there anything I can check on the estop or anywhere else? I plan to go over everything today maybe there’s a loose cable or something.
No other such reports. The e-stop signal is electrically connected to the power stage on the servo drive, to prevent current being driven, its not just software thing. My suspicion is some wiring issue or faulty button.
I still have the centering problem (5-10 degrees diff at each startup)
I noticed that the ‘‘set permanent wheel center’’ doesn’t reset to 0 the value (after reset, value is equal to 0.58°)
‘‘just set wheel center here for now’’ reset to 0°
I tried to startup the simucube with wheel almost centered, same problem 5-10° degrees of diff.
does anyone else with a sincos encoder have the same problem with firmware 1.0.24 ?
Strange.
Can you run the motor configuration wizard to see if helps?
I looked things over and there didn’t seem to be anything wrong with it. Both wires were screwed in tight and were not loose. Same thing on the connector side to the box. Anything else I can check on the switch itself aside from just ordering another one?
you could always use a multimeter. I’m not sure if resistance check (when not connected to Simucube) would be the best way to try.
Did a resistance checked and it all looked ok. I ordered another estop switch seems like while mine maybe within the acceptable limits its not working correctly.
Hey Mika I noticed the simucube window is not remembering the window “size” setting. If I make it smaller it won’t stick so every time I open the the tool configuration its huge.
I will check that the size is not huge by default for next release.