Compilation error and Analog input axis for FFB

[SebLaser]

Thank you for your code which is very detailed. I have so far succeeded in compiling the button box by adding an small XY joystick on the following bytes. Loading the code on the nano is done well. I will use it too move the mouse on the screen. Now i plan to program the leonardo but i can't compile your code. In USBDesc.h in the last lines i have the compilation error 'Joystick' was not declared in this scope. I follow your "How to compile the source" explication, a lot of errors are gone but this one remains. In HID.cpp the word Joystick is black, not orange: Is there a librairy missing? Thank's for your help.

[SebLaser]

Sorry, i found the mistake. In the IDE, under tools the nano board was selected from my previous project... I choose leonardo and now there is no error but a lot of warning with arduino 1.8.18:

D:\Partage\FFB\brWheel_my\brWheel_my.ino: In function 'void setup()':
D:\Partage\FFB\brWheel_my\brWheel_my.ino:151:29: warning: large integer implicitly truncated to unsigned type [-Woverflow]
   CONFIG_SERIAL.begin(115200);
                             ^
D:\Partage\FFB\brWheel_my\ffb.ino: At global scope:
D:\Partage\FFB\brWheel_my\ffb.ino:63:1: warning: invalid conversion from 'void (*)(uint8_t, uint16_t, uint16_t) {aka void (*)(unsigned char, unsigned int, unsigned int)}' to 'void (*)(uint8_t, uint16_t) {aka void (*)(unsigned char, unsigned int)}' [-fpermissive]
 };
 ^
D:\Partage\FFB\brWheel_my\ffb.ino: In function 'void FfbHandle_EffectOperation(USB_FFBReport_EffectOperation_Output_Data_t*)':
D:\Partage\FFB\brWheel_my\ffb.ino:483:23: warning: invalid conversion from 'uint8_t {aka unsigned char}' to 'const void*' [-fpermissive]
     LogBinaryLf(eid, 1);
                       ^
D:\Partage\FFB\brWheel_my\debug.ino:146:6: note: initializing argument 1 of 'void LogBinaryLf(const void*, uint16_t)'
 void LogBinaryLf(const void *data, uint16_t len)
      ^
D:\Partage\FFB\brWheel_my\ffb.ino:505:23: warning: invalid conversion from 'uint8_t {aka unsigned char}' to 'const void*' [-fpermissive]
     LogBinaryLf(eid, 1);
                       ^
D:\Partage\FFB\brWheel_my\debug.ino:146:6: note: initializing argument 1 of 'void LogBinaryLf(const void*, uint16_t)'
 void LogBinaryLf(const void *data, uint16_t len)
      ^

And more if i use arduino 1.8.19 I will try to download tomorrow.

I would like to take this opportunity to ask you if you have already made a potentiometer version for the steering wheel because in my arcade cabinet there is no encoder.

[ranenbg]

Hi, you can just ignore all those warnings, this part of the code is used for debugging of DirectInput protocol for FFB. In normal operation it is not enabled, so it doesn't matter. Congrats on successfully compiling the code and making the change in button box code.

I didn't make a version where the X-axis is controlled by a pot, as this is not desirable due to lots of noise on input that will be reflected in the FFB signal. However, now that you have the code to compile, it's very easy to make such a change. Just before a function that sends USB data is called, you can remap one of the pedal axes into an X-axis. You would of course not be able to use that pedal axis anymore, so you could use for example handbrake axis for this purpose.

edit: if you want FFB to work with that analog axis, you have to make a change also in the part of the code where an encoder position is sent to a function which calculates FFB, there you have to put this analog axis values instead of encoder. You have to be very careful when you do what not to waste MCU time, because the code is timed where FFB and axis/buttons are updated only at 2ms intervals. The analog axis must be read only at those intervals and not at all times.

[ranenbg]

I just did some testing and it turns out you can map any other axis other than X-axis as a steering input and wait for it - the FFB will still work :)

In LFS (live for speed) I've set steering on Y axis and I do get the ffb working normaly. So, no firmware changes are required for this !

The only downside is that all firmware internal ffb effects (active only in desktop) will still be tied to the X-axis. Those are: damper, inertia, friction, autocenter spring and endstop. These forces will not be working, because without encoder connected -> X-axis will always stay at 0deg.

This is not so much of an issue when you are using a pot for a steering wheel, you anyway have to make some kind of mechanical endstop to prevent braking the pot by turning its shaft past max rotation alowed angle (about 300deg lock-to-lock).

Good news is that once you enter a game it will take over the ffb and it can still send all ffb effects normaly. Just the internal ones (added on top of what ever game sends) that you can enable by clicking on a red square next to some sliders in GUI, will not work. Usualy, people have those turned off anyway.

[SebLaser]

Hi, sorry for the lack of response. I have made good progress on the subject. Adding an AnalogRead worked well as well as with desktop effects. The FFB is better than with my previous solution (ArduinoJoystickWithFFBLibrary), in certain games it works whereas before nothing happened. But I realize that there is noise which results in jerks in the steering wheel, so I am going to install an encoder.

I managed to send the information from my little joystick via the following two bytes to the Leonardo.

I also managed to give a different name to the arduino in windows by modifying the files in your directory, so it is indeed possible contrary to certain comments.

I want to add the possibility of having a spring effect on top of the game effects. (Some games only send vibrations so the steering wheel does not return to center.) I haven't found what deactivates the desktop effect when you launch a game. So I think I'll code a little extra function.

I'm progressing little by little, but the result is pretty good thanks to you. When it is fully functional I will just have to make a copy and paste because it is a twin cab! Thanks again.

[ranenbg]

Hi, congrats again on your progress. About analog X-axis for ffb - it is noisy, I told you so :) but it's good that you tried it and saw for yourself that encoder on ffb axis is a must afterall. At least for an ffb wheel, I guess for gamepad one could get away with just rumble motors.

This other ffb library for arduino you mentioned probably has just constant force effect implemented, so that's why it didn't work with a game that only sends periodic effects. In that sense my firmware is the most complete compared to other ffb implementations for arduino.

Yes, ofc, one can just change board name and it will appear in windows like that under game devices.

Autocenter spring effect is handeled internaly by the directInput protocol itself. There is a special flag for it and this you can't change. What you can do however is to add a desktop centering spring effect, that will always stay on once you enable it. Have a look at how I implemented this for other desktop effects like damper, friction and innertia. To keep consistency with my firmware, in principle you just need to add "square button" next to the spring gain slider, this will send an effects configuration byte to the firmware. Then in ffb.ino add one more if statement which checks this bit and adds one more spring effect on top of ffb signal. Anyway, I should also do this sometime if I find enough motivation, it's a good suggestion, tnx.

[ranenbg]

The updated firmware v230x now supports selecting any axis to be tied with the FFB axis, including the analog axis with a pot. I'll close the issue.