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.

... i added 3 pictures, from the ffb-axis "gears" to the first page ... I hope this pictures help to understand, what i meant with 'cogs' and how the motors have to be adjusted to be a little bit closer to the plastic cog-segment axis. Close enough to eleminate the play, but relaxed, to avoid higher forces. After adjusting and fixing the motors with the two screws, the motors can be additional fixed with some soft glue (see third picture).

Hi Wrap, hi Faustus, sorry for my poor english, i better should have use a dictionary, as usual :book: I actually meant cog (or cogwheel). If i find the time, i will add some pictures/drawings to explain this simple modifications, since a picture still tells more then thousand (wrong english) words :music_whistling:

Hello Evgeny_781, the rudder axis (pedal) is special in respect to noice. The rudder potentimeter is connected over a long cable and the 0..3.3V signal receives some addional noice because of that. The noice of all axis is filtered already, by applying something like a 'deadband' around the signals mean. But if the noice amplitude is bigger as the deadband, you will see some small variations in axis input values. You have two options to reduce the noice seen by the analog digital converter (ADC), yourself: 1. improve the quality of the USB power supply (5V) by using a good USB-Hub 2. if you are able to solder a little condenser (SMD) inside the main unit, this would help a lot. Look for (C21..C25) one of this is filtering the signal from the rudder (Logitech saved apparently a few cents for this condensers)

'master' and 'ffb_experimental' branch are identical currently and i am assuming you are using the latest version of my patch. My ffb 'center play' related modification, is based on an increased 'minimal voltage' for the dc motors. The minimal voltage is essential to get an acceptable 'center play' window, because any dc motor doesn't start to output a torque, before all the inner friction forces are compensated. Hence, an optimal voltage, will result in the smallest possible "center play" window. Now the problem is: each device is different, because of aging, modifications, etc. Unfortunatelly, there is now easy way for me, to export this parameter (minimal voltage) to the user. So i finally implemented a value, that is basically a compromise. For me this value works perfect, because i did some simple, but very usefull modifications. fixed the two (roll) ball bearings on their axis (this axis is produced with a diameter to small) moved the motors closer to the cog-segments to eleminate the play within the cog's replaced the grease for all slide bearings with a higher viscosity grease I would recomment to adapt your device accordingly, because you will get an very precise device this way and the oscillations will stop.

A feature of a former version was, to downscale the springforces, in a way that it is proportional over the full control way. But i had to revert this modification, because it turned out, that many application adapted to the original behavoir (saturation at 12.5%, with 100% coefficient). By the way, the spring condition effect is used not only for simulating a spring, but for many other effects (by modulating the offsets, saturation, deadzone). Thats why i recommended you, to use my simFFB version and play with all params, to finally get a feeling for the flexibility of the spring condition effect and its params. For example: if you set the coefficient (called force in simFFB) of the spring effect to ~12% (spring saturation 100%), you will get an almost proportinal spring, saturating exactly an the max/min of the control way.

... yeah, thank you. Maybe it is time to merge 'ffb_experimental' back to 'master'. I think this 15g additional weight in your stick may explain the oscillation you observed, since i really can't reproduce this behavoir here. Theoretical i could reduce the minimal voltage (pwm) further, but this would increase the 'center play' too. If you open your device next time, you could apply a grease with higher viscosity for x axis slide bearings. This would damp the stick and stop the oszillations.

... thank you for testing. There is a new version ready for testing in 'ffb_experimental' branch: https://github.com/fred41/G940-firmware-fixes/tree/ffb_experimental I reverted the spring coefficient downscaling (saturates now at 12.5% max./min. position again). Can you test it again please? To help me to understand the unwanted vibration phenomenon better, could you answer the following questions, regarding your setup, please: - did you any modifications on your main unit (grip, ball bearings, motor, clogs, lubrication)? - what ffb settings do you use in the profiler? Thanks again.

... ok, thank you. I observed this micro oscillations close to the center too. This was caused by the increased minimal voltage in combination with an noicy position input. This problem should be fixed now (by using a filtered position input for motor voltage calculation instead). I uploaded an update here (for testing only): https://github.com/fred41/G940-firmware-fixes/tree/ffb_experimental Please try it and tell me how it feels/work for you.

Ok, point taken and paddled back. The last commit is reverted (removed from 'master') and can be found in the new 'ffb_experimental' branch now: https://github.com/fred41/G940-firmware-fixes/tree/ffb_experimental Everybody interested in a bit research can follow the ffb related development here. As soon as it becomes stable, it will be merged in the default 'master' branch again. @Doktor_Faustus, with 'kicks in almost all the time' you mean something like 'oscillation', right?

... i think this would indeed be an surprising turn, but who knows ... So, lets bridge the time with a bit DIY and have fun this way:smilewink: