Showroom (In Progress) DIY FFB non synchronized shifter for American Truck Simulator

I’ve had this idea in my head for some time now. One of the biggest draws, for me at least, when driving in ATS is the satisfaction of smooth gear changes when using a non synchronised transmission. The idea is simple. You match the engine speed to the road speed so the gears mesh correctly and the gear changes are smooth. To enable this in the game requires setting: uset g_hshifter_synchronized "0”. The result is floating or double clutching for gear changes is much more realistic as you must manually adjust engine rpm. This provides an entirely new challenge compared to regular racing games and takes a good deal of practice to master. The trucking world has seen a massive decline in the use of these once common transmissions. Fewer and fewer truckers today know how to drive them properly. As a European, I'm unlikely to ever come across one but through ATS it’s possible to imagine driving an old 18 speed Kenworth or Peterbuilt.

My first solution was to go out and buy an Almar shift knob for my G27 shifter. This gave me the required range and splitter switches for driving an 18speed but, I still felt something was lacking. The problem is that your physical stick will slot into gear irrespective of whether you have matched the rpms correctly. The result is the in game truck coasting in neutral, making a grinding noise, while your physical shifter has slotted home into its gate as if nothing is wrong. This is very unrealistic and really hampers immersion.

I did my research on 18 speed Eaton Fuller transmissions and non synchronised “crash boxes”. I have come up with a design which I think will offer a good simulation of real world behaviour.

I’ve kept the idea as simple as I think it can be. Two pieces of information are all that’s needed to achieve the desired results. We need to know:
1. When the physical shifter is selecting a gear (button pressed).
2. When the game is reporting the truck is actually in gear.

I wrote an Arduino sketch for a pro micro to act as a game controller. This will output the gear ‘button’ presses to the sim. I also pass this information by i2c to an Arduino Uno.

The Uno is receiving the gear state from the game from serial data via game dash. It also receives the button press for gears from the pro micro (via i2c).

Now that I had the required data there were two scenarios which needed to be simulated.

1. Physical button pressed but no gear selection reported by the game.
2. Physical button pressed and gear data received from the game.

For the first case I needed the gear lever shaft to vibrate to simulate gearbox grinding. This is the result of the rpms not being correctly matched. In addition I needed to make it so the lever would not be able to slot fully forward or back into its gate. The result: we try to find a gear - gearbox says no - gear lever vibrates - maintenance bills go through the roof :-(

The second case requires the stick to be able to slot into position as the rpms are synchronised. The result: we try to find a gear - rpms are aligned - gear lever slots into position - no maintenance charges

The build is still ongoing. Here is a picture of some of the components. The fore and aft movement is locked by two electric solenoids controlled by a relay. The vibration is provided by a vibration motor to be mounted on the gear lever also controlled by a relay. Power is from a 12v supply.



The next picture shows what I’m calling the syncro mechanics. The limit switches which record forward and rearward movement of the gear stick are mounted on spring loaded hinge arms. The switch can be engaged by the gear stick but the arm is locked in position and prevents the shifter moving fully into its gate or ‘in gear’ position. The solenoids provide the mechanism for blocking the movement. When the solenoid barrel retracts, the hinge arm is free to rotate and in turn, allows the stick to travel into the gate.




This picture shows the fore and aft gate mechanics. Two bearing wheels are held against MDF tracks under spring tension. The wheels are in turn connected to the gear stick with rose joints. Once the barrels of the solenoids in the internal synchro mechanics have retracted the stick is free to drive the wheels over the track (either forward or backward). The shape of the MDF track provides that familiar ‘clunk’ as the stick slots into gear and it also serves to hold the stick in position.




What about the other four gear positions? I had originally planned to use six spring loaded limit switches but the mechanics would have been too complex. By using just four switches I am able to output all six gate positions. It requires two additional switches. One to be mounted to the left and one to the right of the main mechanics. They are actuated as the stick is moved to the left or right. A series of 'if' statements in the Arduino micro provides the logic to interpret the switches being pressed and output the six possible positions as game controller button presses. Before mounting the additional switches I decided to first fit the mechanics and mock up the final design. I had received the final component from the States to complete the look and feel of the shifter. A real Eaton Fuller 18 speed shift knob with an EasyJake switch.




With the gear knob on the shaft and cut to a comfortable height (the unit will be floor standing) I found that the throw was excessive. The stainless steel construction is also quite loud due to the metal on metal design and it is also going to lead to wear.




I’m going to re-cut the H pattern on the top plate and this time use a plastic chopping board from a €2 shop in place of metal. Once I finalise the H pattern size I can move on to fitting the vibration motor, additional spring tensioners, additional switches and electronics.

More to come soon....

I got a cheap chopping board to redo the top plate and H pattern.



I have cut it to shape (still need to sand it). I’m sure there are specialized blades for cutting this stuff. I really struggled to get through it. I used a jigsaw and had a lot of trouble with the blade getting caught up and melting the plastic. I think it looks ok. I’ll be covering the H pattern with a boot anyway.



Hopefully the plastic will be strong enough to stand up to the abuse. Judging by how hard it was to cut I think it should be ok. I might make a steel plate slightly smaller than the existing lugs to sit over the top and reinforce them.



You can see the throw has been greatly reduced. I think this will be a lot more comfortable. Now I can proceed with the remaining two limit switches and mount the vibration motor. By that point I will be on the home stretch.

More to follow....

Another little alteration had to be made to the spring arms in the synchro mechanism. I had done some reading up on electric solenoids. It seems it’s not a good idea to leave the coils energized for more than a few seconds as they are prone to burning out. I had factored this into the initial design. The Arduino code only fires the solenoid for 1.5seconds (more than enough time to move the gear stick into its gate). I had counted on the spring hinge having enough force to drive the solenoid barrel back up into its housing when pulling the stick back out of gear. The spring force from the hinges lacks the force to drive the barrels from the solenoids reliably and the arm would some times stay in the ‘in gear’ position. I’ve cut a few more springs to size and secured them in position below the spring arm mechanisms. This now ensures the arms will return to their normal orientation when the gear stick is moved back into neutral.



In addition I’ve completed a mounting bracket for the vibration motor and secured it to the gear stick shaft.



I had to come up with a bracket which would offset the motor as it is too large to fit above or between the side plates of the main mechanics. I will have to see how this offset weight plays out once I add a tensioning solution to center the side to side movement of the stick.



To be continued....

I have the shifter wired up and tested. Unfortunately I'm having an issue between Game Dash and my Arduino Code. I thought this was working previously but it's only now that I've tested it in the 'live' environment I have found that I have an issue.

I am not getting the gear data from Game Dash. I have tried a few different approaches. The game outputs gear values from -4 to 18. I am applying the following rules in the output editor:

MATH + 5
PAD 3 0

This was based on a previous example posted by @Hoddem. I also referenced his Arduino code for his fan controller.

The virtual output has the same settings. Interface output is G<Dash2>. The virtual output displays G001 etc.. as I change gears. The arduino seems to work if I send the data from the Serial Monitor. Although the arduino only seems to recognise the data occasionally!

Here is my Arduino code.

Code:

#define DEBUG;    //Uncomment to have test with serial monitor
#include <Wire.h>
#include <EasyTransferI2C.h>

//create object
EasyTransferI2C ET;
struct RECEIVE_DATA_STRUCTURE {
  int16_t gearPressed;// variable passed from second arduino to indicate if shifter is pressing a gear button
};
RECEIVE_DATA_STRUCTURE mydata;//give a name to the group of data
#define I2C_SLAVE_ADDRESS 9//define slave i2c address
//declaring global variables
int GearGameDash = 0;
int bufferArray[4];
boolean oldGearState;
boolean inGear = false;
const byte relay_pin_solenoid = 7;//assigning Arduino digital pin 7
const byte relay_pin_vibe = 6;//assigning Arduino digital pin 6
const unsigned long relayinterval = 500;//length of time in miliseconds that the solenoids fire
unsigned long relaytimer;//stores length of time that the solenoid relays have been open


void setup() {
  Serial.begin(115200);//initialize serial port
#ifdef DEBUG
  Serial.println("Serial started, enter commands in the form of G000");
#endif

  Wire.begin(I2C_SLAVE_ADDRESS);//initialize i2c
  ET.begin(details(mydata), &Wire);//define handler function on receiving data
  Wire.onReceive(receive);
  pinMode( relay_pin_solenoid , OUTPUT);//setting the solenoid relay pin as an output
  digitalWrite(relay_pin_solenoid, HIGH);//setting the voltage on the solenoid relay pin
  pinMode( relay_pin_vibe, OUTPUT);//setting the vibe motor relay pin as an output
  digitalWrite(relay_pin_vibe, HIGH);//setting the voltage on the vibe motor relay pin
  oldGearState = false;
}

void loop() {

  ET.receiveData();
  readSerialData();

  if (inGear != oldGearState) {
    gearRelay();
    oldGearState = inGear;
  }
  if (relaytimer > 0)
  {
    if (millis() - relaytimer >= relayinterval)
    {
      digitalWrite(relay_pin_solenoid, HIGH);
      relaytimer = 0;
    }
  }
  
  vibeRelay();//function to control the shifter vibration
  
}

void receive(int numBytes) {}

// This function checks for Gear data from SimTools GameDash

void readSerialData() {
  if (Serial.available() == 4)  {  //if 4 bits available in the Serial buffer...

    int i;
    for (i = 0; i < 4; i = i + 1) { // read and label each byte.
      bufferArray[i] = Serial.read();
    }

    if (bufferArray[0]  == 'G') {
      GearGameDash = ((bufferArray[1] - 48) * 100) + ((bufferArray[2] - 48) * 10) + // Take values 1-3.
                     ((bufferArray[3] - 48) * 1);
      if (GearGameDash == 5) {
        inGear = false;
      }
      else {
        inGear = true;
      }
#ifdef DEBUG
      Serial.print("The Gear to a Value of:");
      Serial.println(GearGameDash);
      Serial.print("inGear has a value of:");
      Serial.println(inGear);
#endif

    }
  }
}

//This function checks if the gear box is synchronized and the shifter is trying to get into gear
//If it is then it fires the solenoids to allow the shifter to slot into position.
//The time is limited due to solenoid duty cycle
void gearRelay() {

  if ((inGear == true) && (mydata.gearPressed == true))
  {
    relaytimer = millis();
    digitalWrite(relay_pin_solenoid, LOW);
  }


}

//This function checks if the shifter is trying to get into gear while the gear box is not synchronized
// If it is then it fires the vibe motor to simulate gear grinding on the shifter.
void vibeRelay()  {
  if ((inGear == false) && (mydata.gearPressed == true))
  {
    digitalWrite(relay_pin_vibe, LOW);
  }
  else  {
    digitalWrite(relay_pin_vibe, HIGH);
  }
}

If @yobuddy or anyone else familiar with Game Dash could take a look I'd really appreciate some help.

Crisis averted. If you want to have game dash communicate with the ard then it helps to disable the serial debugging in the sketch!

This is a good idea.

I have noticed a few more recent racing sims (pCars2 def does it, can clutch start your car too..!), especially on cars with dog engagement/racing transmission but even syncro will allow you to shift clutchless if you synchronize the RPMs.

I am into racing, specifically rally and this is commonly done while racing. You only really use the clutch to get off the line, then you two foot the gas and brake the rest of the way synchronizing your shifts.

With a dog box, you can be more rough and quicker and be slightly less synchronized and it will clunk in (plus is stronger).

With a syncrobox, you have to line up the revs pretty decent or you'll grind.

I would absolutely love to have FFB in the shifter for this. I hate that if I screw up on a shift my only feedback is hearing a grind in the game and knowing it didn't go into gear..usually it'll clunk in a second later or if you break the load..but I would love to feel it in the shifter.

Probably the biggest issue would be getting FEB output for this..?

More specifically even for your app, any manual truck regardless of age would be similar and can be shifted crotchless if you match the RPMs. Obviously the newest trucks are auto but around here even a ton of trucks are still manual. My gfs dad is a trucker and was only given an auto like a month ago and he hates it.

Regarding having solenoids latched all the time - it depends on the solenoid!

There are automotive "solenoids" (used as relays for high current) designed to run constant.

There are also latching designs and off the top of my head generally the holding current is a lot less than the initial activation current, lessening the load on the coil.

That’s good to know. The solenoids I purchased are cheap eBay versions and they didn’t provide information regarding latch time. I thought better safe than sorry.

Of course, always better to be safe than on fire! Just thought I'd let you know that there are ones that should be able to do what you need.

i confused...are you try build shifter with rumble feedback or self aligning feedback..??

I’ve no idea what ‘self aligning feedback’ means!
It’s a non synchronized shifter with force feedback. It behaves the same way as a non synchronized manual 18speed eaton fuller transmission like those found in many older Kenworths, Peterbuilts, etc..

I think a design like this would easily be able to do a syncrho style and a dog box style. The main differences are how quick you can shift, how synchronized the drivetrain must be. I have never driven an older truck but I assume the dogs on their boxes aren't too spaced thus require precision matching. Racing dog boxes space the dogs out more so you can shift quicker/more delta RPM. Syncro will try and help even out the speeds more but ultimately it still needs to be synchronized.

The FFB we need for an accurate feel for all manual transmissions is:
1. Ability to lock out a gear, e.g. idling in neutral, can't shift without clutch.
2. Ability to "grind" when game is grinding, I would imagine using a motor of some sort synced to the engine RPM/transmission RPM delta, higher delta the faster the grinding (you can hear the grind slow down as the revs match and eventually pops into gear, assuming you keep forcing the grind)
3. Some extra resistance to pulling out of gear when a load is applied to the engine, break the load and that resistance should go to zero.

I plan on making a video soon analyzing how many sims implement manual transmissions compared to the real thing. I never thought about doing an 18spd but couldn't hurt maybe. Always wanted to play with truck sims but with a tiny wheel and no buttons for the splits, not excited about it.

I know pcars2 definitely implements manual transmission 100% correctly. It also has udp data output. Could be good for testing. Again, I know you are specifically building for truck SIM but I am interested in this project as I said it would have use elsewhere, I do not mean to hijack your thread at all - just discussing ideas.

Here's an idea.

3dPrint a smaller version of a manual gearbox, clutch, flywheel and spin the flywheel to engine RPM and connect the shifter to it and have real FFB?

Lmao kidding

looks interesting...
-first of all, maybe we need something to comunicate with computer/game, in this case we can use arduino
-you need to write code for that because there is no sw fw for that in this time (maybe)
-do you ever heard this

we can implement that system, and we can simplified that if we just use that for hshifter

let me know if you have easier way to do that because i know nothing about coding...hahahahaha.....

I'll check the video a bit later. I have over 25 years coding experience in many languages as well as EE and Arduino experience. Happy to help, I would love to make something like that as I don't think there ks anything like it anyway.

Would definitely be easier to get it running on PC. Console games would absolutely require udp output probably.

Imho, for feedback to feel real, we need to know at least:
- Current gear #
- current gear ratio, final drive ratio and wheel speed OR output shaft speed (dont think anything will output shaft speed but we can calculate back from wheel size/speed, final drive and gear ratio?)
- engine rpm
- clutch status..?

I say that because when you grind a gear, depending on the delta angular speed depends on the "speed" of the grind or if the speed is matched, no grind.

I would envision some sort of grinding feedback. I am not sure how to mechanically implement the feel. One easy idea is to use sort of thr same mechanism you would find in a manual transmission and spin the input/output shaft according to the games input, with some sort of mechanism to simulate either syncrobox or dog box notchiness in the middle.

That is probably way overkill and complex however..but I would love for it to feel decently real. I drive a m/t daily and don't often use the clutch (when I do, it is only going INto gear to absorb some energy in the drivetrain, before shifting into gear, I do not clutch, I use the throttle to break the drivetrain load to pull it out of gear, this keeps the input and layshafts syncronized (like double clutching except using throttle manipulation to break the engine load instead of the firsr clutcnimg event) and always rev match regardless anyway.

I also have some rally racing experience and decent knowledge about how manual transmissions work and how they should feel. I do understand how an 18 speed shifter works, however, regarding how a shifter should feel in a truck. I can't really say but I would imagine the same mechanism can be used in both applications.

Will have to do some mechanical brainstorming. But if we can build a good mechanical design, I can handle the hardware/electronics/software/firmware

I should have watched that video first.

That is definitely workable design idea, only briefly looked, I will look into it more soon.

imho, the game will do all of that, because different car have different gearing. and we can make/add artificial effect if game doesnt have telemetry about power train (switch betwen that). but the game should have telemetry about gearing, because simhub can read all of them (even dirt series have that too).

for me the main problem just sw and fw. and finally if arduino can make output signal such as pwm, duty cycle or analog output for actuator driver (not specific driver, so we can make whatever the model depend on creativity), we can make mechanism for that.

Arduino can definitely do the things we need.

I love this idea, i am just getting back onto my bus driving sim build (for Omsi2) and whilst most bus's are auto, there are some manual ones... usually only 5 or 6 gears tho... but i do have ETS2, and would be nice to drive an old 18 speed with range change and splitter gearboxes,

i'm all for as much feedback as possible... i plan to mount a solenoid under my air brake pedal to clunk on and off when the ABS kicks in on the bus (it handily has a light on the dashboard that lights up in time with the pulses)

i'm was really hoping a simple force feedback joystick could do all the gear crunching and that tho... but it seems the best they got was holding it in gears and a very rough H gate.


Re: solenoids, maybe get some from a pinball machines flippers,
they have 2 coils, a 'fire' coil which is heavy wire and a short wind, so it produces a big clunk and moves it fast, and the 'hold' coil which is a much lighter winding of more turns, this holds the solenoid plunger in almost indefinitely, there's a leaf switch as part of the mechanism to change the coils over from the single stat button on the side of the machine.


OR, maybe program something on the arduino to switch some resistance in with the single solenoid coil once it's pulled the pin back,

sim hub can probably do what you want using shakeit and some rumble motors from a gaming pad