fred41

Below you see the flow of FFB events send from your application (game, simFFB or FFB Testtool or ....) to your G940 device: | application/FFB API | ----> | driver (windows) | ----> | G940 | The driver translates the FFB-API events to USB commands the G940 can understand. LGS settings (slider, checkboxes) are affecting this translation, by adjusting the scale of the parameters in the driver. This LGS settings are persistent, this mean's you only have to do that once and the driver will use the last settings in the future. All FFB events parameter are scaled according your LGS/driver settings. Example: SimFFB 50% spring force, LGS 50% global, 100% spring ==> 25% of the spring force is send to the G940. (this above is from my personal experience and hence perhaps totaly wrong ;)) Finally, if you fresh plug your G940 and no FFB application is running, you will only see/feel the spring forces set in the firmware. This spring forces are stronger for 'hand off' and very soft for 'hand on' stick. This makes sense in my opinion, because this allows us to use the G940 in applications without FFB support more comfortable.

Hi KriX, as said, SimFFB is mean't to run in the background of non FFB applications, to adjust 'conditions effects' (like 'spring' and 'damper'). Your 'deadman switch' seems to work as expected. The part of the patch you mentioned, will only have an effect, if you modified/disabled your sensor electronic. You will get FFB effects (other than conditional effects) only, if an FFB enabled application requests/control them. You can generate some of the available FFB effects on windows with a little FFB Testtool: https://fs-force.com/support.php#ForceTest

I think it is not a good idea to implement additional FF-effects in the firmware. Try to imagine the following: The controller inside the G940 is a little 72MHz cpu and is already busy with processing all the inputs and the calculation of up to four condition effects. Apart from that, i don't have access the source code, that means i am coding in machine code ... So i am sorry i can't really help you.

Hello Labuzan, i did'nt tested FS2020 yet, so i can't say if it supports MS's 'ForceFeedback API'. But SimFFB is mean't to be used in the background of applications/games that does'nt use the FF-API itself, so i would assume, that FS2020 is initializing (and probably supporting the whole FF-API) at start and hence SimFFB is loosing the access to the API (only one can use this API at a time).

@BMaxis, i have scaled this a bit back in direction of the original scale. Please try it with your 'washer installed' setup and let me know.

Hello BMaxis, thanks for your feedback. You are right, i changed the scale of the x- and y- axis to improve the movement ampitude and the precision of the stick movement (it is using nearly the full movement range now). The problem is: if your hall sensor is not exactly enough in the center, you get what you desribed above. You can try to fix this by moving the hallsensor PCB carefully in the right position. If that doesnt help, please let me know. I can change the scaling to be more tolerant, against misalignd sensors.

Sure. First, yes, it is expected/normal. There is a difference between the gear-constructions for the x- and the y-axis. Simple spoken, the stick is more 'in touch' with the motor for the x-axis, hence you don't feel the inhomogenity of the dc-motor magnetical field that much/early, compared to the y-axis. Once your sensor works again, you will be able to confirm this. That's the reason why i personally prefer to use the lower part of the whole force range.

The auto-centering effect in hands-off condition (sensor not covered) is not adjustable for the user, it's parameters are fixed in firmware! There is a simple way to check the sensor's functionality: 1. Connect your main-unit to power and USB port of your PC 2. Move the stick a bit (maybe 30°) away from centre position 3. Now cower and uncover the sensor multiple times There should be a difference in force for both states (covered/uncovered). If you dont feel a difference, your sensor is dirty or broken, as i already assumed. To clean or repair/replace the sensor, you have to disassemble the stick obviously, but that shouldnt be a challance, actually.

Hi Joe, there is an optical sensor in the main stick grip (on the right side). If this sensor (also called dead-man switch) is dirty or damaged, you perhaps will get only the auto centering effect, meant for hands-off condition. The whole force feedback functionality is only available if the optical sensor is active (hands-on). Maybe you try to clean this sensor (brush, alcohol). In the worst case, this sensor could be damaged or internally disconnected and needs some repair. Hope it helps and let us know please, Fred41

... for the sticky rubber: try talcum or try to remove the sticky coating comletely (isopropyl may help) ... The mode switch position is reported by the firmware, together with all other buttons and axis. It is the driver, that translates the mode switch position to profile selection (iirc). If you are on windows 10 and familiar with c, programming, you could write your own driver: https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/virtual-hid-framework--vhf- BTW: your signature calls lovely memories to my first pc, except my budget limited me to a 386sx16 and 2mb RAM, but at least i got a 387sx too :)

The detailed FFB behavoir is usually configurable in your simulation application. For applications that does'nt support the FFB api, there is a windows tool called 'simFFB', made to setup some condition effects, like spring and damper, in the background. You will find a special version of 'simFFB' in the first page of this thread.

@Necro, i would try the following: 1. run the unpatched 1.42 executable, to ensure G940 is uptodate 2. make a backup of the unpatched 1.42 executable 3. patch the 1.42 executable, to apply the improvements to executable 4. run the patched 1.42 executable, to apply the improvements to your G940 Greetings, Fred41

... check the ffb_experimental branch of my repository: https://github.com/fred41/G940-firmware-fixes/tree/ffb_experimental ... and better don't torture your G940 gimbal to much, with this heavy grip :cry:

... maybe there is a much more simple solution for this problem ... If i understand you correctly, you are using the original logitech PCB from inside the G940 grip in your new virpil grip and you wish to simulate an always taped deadman switch, right? If so, just look for J7 at the bigger PCB (where the 4 wire flat cable to the deadman switch PCB is soldered). Disconnecting (desoldering) pin 1 should do the trick. In case this gives you an 'always untapped' result, you need to connect this pad to ground. Let me know ...

... thanks for any friendly feedback, all. @Drakoz, thank you for linking this thread and my patch repository. Your announcements, regarding the improvement video, are very welcome and i think many G940 users are waiting exactly for some help of this kind. @aeliusg, the hall sensor itself (MLX90333) in the G940 is very well calibrated/programmed. But yes, the calculation of all the forces and especially the spring/damper forces is done in the firmware, so there is some potential to adapt FFB behavoir.