SimuCUBE Open Source Firmware Development Update Thread

The pedals would connect X11 like this:

not asking about how to do it, which is pretty clear.
Just asking: did anyone on this board actually do it?

I use 14 buttons as buttons do not need other features

Currently in the Beta the Analog Axis points are working fineā€¦ The button points have not yet been implemented.

@Mika - The Button Configuration (I think as Beano is describing) is sort of the standard for button controller interface as you can then choose what pin gets output to the game as a certain button numberā€¦ I think right now with MMOS and the direct simucube button you have to have the correct button in the correct position to get the Button number you wantā€¦

i.e. button #1 on your controller (if that is what you want it) has to be attached to the position for button #1 on the board.

With an interface for buttons and pins you would then just be allowing the user to remap the buttons to different outputsā€¦ i.e. button placed at Pin #1 could be changed to output on Pin #5ā€¦ This might correct things for some games that have fixed button positioning or those that are OCD and want certain buttons mapped to certain Numbers. However, so far I havenā€™t really found a modern game that doesnā€™t do this mapping in game letting you select any button for any function.

The Big thing however would be if you were to allow buttons to be of different stylesā€¦ for example linking two of the pins together to be an encoder input that would allow for directional input and then output the correct button press to the game or turning an analog input into a Button press input or visa versa turning a single pin to variable.

I think the most useful thing would be the Encoder (decode) with two linked pins as if it could be tuned to the cheaper encoders as to not get the bounce issues it would allow anyone to set-up encoders easily. (might also allow you to add some things to firmware where it can use the encoder attached to change MMC on the fly to allow force reduction or increase while driving (which would actually be a really cool feature).

Anyway I just donā€™t know how complicated the button mapping should be unless it makes for added features such as the encoder support, or the Matrix Support, however, Windows has a 32 Button Max on a game device so if you matrixes and got more than that you might have to have it tell windows it tis two separate devices.

I currently use the BlueHID controller that has a shift feature on the buttons so that one pin can act as two buttons and I essentially have more Buttons on my wheel with that than what windows will allow.

Actual update:

The Australian alphamonkey has the next build with bootloader, firmware updater and some small bugfixes to test when he wakes up. If all goes well, I will release it tomorrow.

No actual new features yet.

About the buttons: I shall start with simple all buttons stuff, and then we will decide what we implement as extra.

2 Likes

Analog axes, digital buttons (direct and matrix) and rotary encoders, one selectable input type per RJ45 port would probably get most of the use cases covered.

MMOS had support for Logitech G25 shifter SPI and now that G29 shifter can be bought separately from the wheel, that would make it cheap shifter solution if SPI is possible from the X12-pins. If we can support SPI, it would make connecting Fanatec rims possible too.

Of course full-on configurable advanced section where users can choose their own pin layout OpenSimHardware-style would be also nice to have, but I guess thereā€™s lots of higher priorities currently.

Idea to be able to control firmware settings is also very intriguing, Iā€™d use it for changing filter settings on the fly. What better way to test settings than adjusting them while driving.

I already hooked up my Fanatec Handbrake to the Simucube and tested it in PCars2, also I did some first test with the Fanatec SQ Shifter. I now know how the Shifter operates, the tricky part will probably to come up with an intelligent way to calibrate it, as it useā€™s two analog inputs to determine the gear itā€™s in and then just output it as a button.

I would need access to actual hardware to make actual things like this. Perhaps we will see if someone from the community can develop the code when we release the main parts of it as open source.

:lol:

Just a short update:

Alpha Monkey doing Bootloader testing with Mika. Going really well, flash on PC A and reflash on PCā€™s B, C and D working wonderfully well. This simply means, once you flash the new Bootloader via the DFUseDemo, you wonā€™t ever have to play with the hardware switches again.

All future flashes can then be done directly via the GUI, without moving the Switch S1. Nice :slight_smile:

Cheers,
Beano

Below sequence of pictures will tell the whole storyā€¦ apologies if I am verbose, but I am just excitedā€¦

1 Like

Very cool!!!
Wake up Mika time to go to work!! :smile:

1 Like

A shift function.
Hey Mika,
Regarding button implementationā€¦
Iā€™ve been using a uhid and bluehid in recent months. I never thought Iā€™d like it, but, the shift function comes in handy. Especially when cycling through settings and menus while racing.
Macros would be cool as wellā€¦ I guess, though I think if used maliciously, it could constitute cheating in certain cases.
I want to try my diy hydraulic pedals out with the new firmware so keep up the good work eh?
Cheers,
Posi

Short question: is there a reason why the git repo on Github is no longer there?
I cloned it in December or January and have been following the work ever since but since a few weeks I get errors when pulling.
Is there another git repo to pull from?

I know itā€™s currently in closed beta (which Iā€™m not part of because I was a bit too slow), but that does that mean that you may not access the code as well?
If so, why?
After all the stuff in the repo doesnā€™t allow you participate without invitation.
Or at least not without putting a lot of effort into it (compiling the thing), although Iā€™d say that if you succeed there, then you deserved your prize. :smiley:

Another question, this time regarding the setup process.

Would it in principle be possible to auto-detect a servo by measuring the resistance and inductance and comparing the values to a stored database?
Or would that be too unreliable?

afaik there are 4-5 very common choices for servos and it might be possible to auto-separate them using this technique.
Itā€™s clear though that it canā€™t work in every case.

The reason is obviously the chinese imitation product, which was shown here and lately on the iRacing forum. We decided to go private for now, and we have ideas on how to get back to public again, hopefully soon. We also have a few ways of telling if the chinese one uses our open source code, if they decide to develop something other than mmos. Fair game, as the license would allow it up until when we removed the repository.

It would be possible, yes.

We decided to go with drc files, because 95+ % of the users already know what servo they have, and the rest typically wonā€™t touch motor settings at all.

Thatā€™s a shame. I hope this turns out well in the end.

Well, we are keeping the configuration software as closed source, so thereā€™s also that hurdle if they want to do something other than mmos.

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.

SPI is possible on the internal X14 connection on the PCB. If there is a developer interested to do this, then we would be interested too. We know it is possible as it is supposed to work with MMOS somehow, but I havenā€™t managed to find the documentation on the interface other than that it is SPI.

I see that there is some ready made code here:

ā€¦ but we donā€™t have any Fanatec hardware at our office. I would be willing to try to port this at some pointā€¦ Any hardware donaters for ā€œundefined period loanā€ in Tampere area?

First, thanks for all your job to the community. :slight_smile: You know certainly that but this is all the effects windows can makeā€¦

https://msdn.microsoft.com/en-us/library/windows/desktop/bb153254(v=vs.85).aspx#dx_DirectInput_loading_ffe

And a program to test these effectsā€¦

https://forums.eagle.ru/attachment.php?s=2c8337fa5e75b46af8dc03fb86071eab&attachmentid=121114&d=1441344690

It could be interresting to have these effects because a lot of games like AC, RF1 and others use fake effects to reproduce kerb effects for exampleā€¦