Not out of the box, but we will facilitate such community development efforts when we release those parts of the source code that are needed to develop such things.
great success today:
data rcvd: 183508
finalizeflash
bytes received: 183508
start crc32
end crc32
request status
boot app from bootloader
------ SimuCUBE BOOT ------
HAL initializations complete.
This is super progress, Mika, thank you for the heads-up!!
If you need me to test, I am arriving back home very early Friday morning my time, will have good time to test the flashing operations then, if needed.
Cheers,
Beano
@mirkeli, thank you for sharing your lengthy analysis & thoughts about filtering! I agree with your thoughts.
More different kinds of filters are being tested and analyzed. The plan is to provide different kinds of filters for user to choose from (i.e. moving average between samples regardless of delay that it causes).
I have already few ideas how to reduce sharp turn overshoot on the current reconstruction filter. More about that later.
Hi, I need to change the MMosFFB rotation angle.
Can someone give me a hand?
The current minimum is 180Âș, I need the minimum to be 100Âș
a greeting
That is not possible with MMOS.
The feature you are requesting is already working correctly in our new open source firmware, which is currently in closed beta testing. Currently the range in that is 20 - 2160.
One way to trick MMOS would be to change the PPR/CPR values so that 180 degrees would be 100 degrees in reality.
Hi, I do not know that hardware, I can pass the new hardware link in beta phase.
When will be the final phase.
The POR / CPR values where they are to change them and thus fool MMos. I can not find them in Granity.
Why can not you change the value to 100Âș in MMos? As I do not know this but at first sight who knows how to do it will not be very difficult.
We have nothing to do with mmos, it was made by someone else.
Thank you, I did not know.
Hi, I do not know that hardware, I can pass the new hardware link in beta phase.
When will be the final phase.
The POR / CPR values where they are to change them and thus fool MMos. I can not find them in Granity.
We currently do not need any more beta testers.
I think the open beta will be released by the end of the month.
The PPR value is in the Machine -tab, FBR - Feedback Device Resolution and the CPR value is in the MMOS settings. The CPR value must be 4 times the PPR value.
You will have to calculate the suitable values.
Great news Mika, do you believe the open beta will have the button system working?
Thanks for your precious job
Wow, you guys are really pushing forward quick.
Cant wait, it will be like early x-mas =)
Button system is in the works.
Thanks for the reply.
Iâll wait for the beta version to come out to the final version.
I find it very complicated to adjust POR/CPR.
It would be nice if the Beta version is added to include buttons, x, y, z, rotary X, rotary Y, rotaryZ.etc. And have adjustment options, similar or improved to the MMF FFB.
Implementing the buttons shouldnât take very long, if all the button inputs are just interpreted as buttons. I could just set them up and the would already show up in the UI correctly.
I was wondering if people would want different types of inputs. @phillip.vanrensburg suggested this project as a base: https://opensimhardware.wordpress.com/pedal-button-controller/
but Iâm still think whether or not to port all possibilities from that project or not. It will become larger project to support any input in any pin. Also, I would like to have one RJ45 plug per input type, so user wouldnât need to cross wire anything between the X12 upper and X12 lower ports. This will limit the types of inputs that can be implemented. Perhaps a configurable âbuttons or other functionâ per port. There are 7 digital inputs in each of them.
What other functions should there be on a port? What are peopleâs thoughts about this?
In simulators today many people use the plate LeoBodnar BU0836A.
The suggestion of @ Phillip.vanrensburg is very good. Since the adjustment is done graphically.
The RJ45: X11s X12s connections are easy to program for buttons, rotary, potentiometers (pedals). I personally have done well with the MMos interface but many people use the Leo Bodnar board because they do not like that interface.
My opinion is that with a single plate of Simucube that has many possibilities is everything in it, buttons, pedals, so no need to attach more electronic boards to the simulator.
Yeah, I know what is possible with the Bodnar board. Iâm just trying to get a handle on what we would be able to support with the one input type per X12 port configuration.
I havenât seen actually pedals connected directly to the simucube. are many people using this feature?
However, Iâve got my paddles and some self made button box with one rotary switch on there.