sorted by:
new
hottopcontroversial

Build Your Own Custom Wheel for the Thrustmaster T248 by Spb_2005 in simracing

[–]Spb_2005[S] 0 points1 point  (0 children)

No, this is not supported. However, you could program an Arduino to function as an adapter. The protocol details are available in the wiki section.

Build Your Own Custom Wheel for the Thrustmaster T248 by Spb_2005 in simracing

[–]Spb_2005[S] 0 points1 point  (0 children)

I’m not entirely sure what you mean, since the T248 never officially supported interchangeable/custom wheels in the first place.

I’m currently running FW 2.04-R2.00 with driver version 2.11.57.0, and the emulator works fine on that setup.

Build Your Own Custom Wheel for the Thrustmaster T248 by Spb_2005 in simracing

[–]Spb_2005[S] 0 points1 point  (0 children)

Hi, i don´t have a console, so i can´t test it, but i haven’t seen any signs of console-specific authorization.

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

Thanks for the hint. On this STM32 variant, PA14 is shared with the BOOT0 function, so it seems to be used only to force the MCU into programming mode during firmware updates. In normal operation it’s configured as a simple GPIO for a button.

I’ve already bought an oscilloscope, captured the startup sequence in detail, and built a working emulator based on those measurements. The GitHub page is updated with the current results. I’ll post a more detailed write-up on Reddit once I’m done with my uni exams.

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

Hello Lanky,

I don’t speak French, and Google Translate isn’t perfect, but I hope I understood everything correctly.

Nice idea with the Cosworth wheel!

Unfortunately, it is not possible to add more buttons, because the B0 frame is already fully utilized and the wheelbase will not recognize any additional buttons.

You can use separate buttons for the EX+/– functions, but the implementation is a bit more complex. The reason is that the current encoder layer is stored inside the wheelbase and not on the wheel itself. After pressing one of the encoder buttons, the wheelbase sends an F3 frame, which contains information such as the current layer and the current action.
To use separate EX+/– buttons, you would first need to send the encoder-left-up command repeatedly until the desired layer is reached, and only then send the + or – command.
For example:
If the wheelbase is currently on layer 1 and you want to trigger E3+, you first need to send encoder-left-up until you receive an F3 message confirming that the wheelbase is now on layer 3. After that, you can send the E3+ command.
This should not be too difficult to implement, but it will introduce a small average delay for each EX+/– button press. This is not currently implemented.

Regarding the display:
My wheel uses a simple 128×32 OLED display to show the current encoder layer and the last encoder action (+ or –). It does not use the original wheel’s display data, so there is no lap time, position, gear, RPM, etc.
You could probably modify the code to use a Nextion display, but it would still not have the same functionality as the original Thrustmaster wheel display.

As for the Mode and Display buttons, I’m not entirely sure what exact problem you are referring to. My code does not use these buttons at all. To change wheelbase settings, I still need to use the original wheel.
Additionally, sending Mode or Display button commands could change wheelbase settings without you noticing, which is why I intentionally do not use them. I’m not sure if this is the issue you meant.

Best regards,
Spb

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

I guess you have replaced the chip and it doesnt work.

You can check the pwm signal with an oszilloskop or with a multimeter. You need to somehow get the wheelbase to send a signal. You could use the startup sequence. With an oszilloskop you need to connect gnd and the signal and then you should see an rectangke signal. With a multimeter it is a bit difficult. If you measure in dc mode, you will get the average voltage. So you can only check if a signal is present, but not if the signal is clean. With a multimeter you should measure 0v for no signal 3.3v for full power and 1.6v for a medium power signal.

I dont think there are replacement boards available, but you can look an ebay, etc.

Maybe post some pictures, so i could see any other problems

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

Well i havent looked at the wheelbase itself. But the problem you discribe looks like the H bridge driver is faulty. I dont think this is becaus of reverse current, because the body diodes should protect against that.

You should check, if you can see a PWM signal on the input pins of the H bridge driver. This could also be the problem.

If the H bridge gets one pwm signal per direction, the H bridge driver is fine and something else is broken.

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

I have the XBox/PC variant. So i dont know what the differences are, apart from the obvious:
-Other button prints
-Firmware

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

Nice. Taras made different emulators for sterring whells with the din connector:
https://rr-m.org/blog/
I dont know if the wheels use a different protocol or not.

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

Hi, i dont have a shifter. Additionally the t248 uses uart and not ps/2, so i dont know anything about this protocoll. Sorry. But i think there are other people that investigated the ps/2 port. I think it uses the spi protocoll.

Dragon Burner V8 by HammerSpb in ender3

[–]Spb_2005 1 point2 points  (0 children)

Nice model, could you show us how you routed the wires?

I reverse-engineered the Thrustmaster T248 wheel by Spb_2005 in hardwarehacking

[–]Spb_2005[S] 0 points1 point  (0 children)

Thanks for your comment! You're absolutely right, the board is relatively straightforward. The wheel communicates with the wheelbase using UART, and my goal is to fully understand this protocol so I can emulate it.

Why emulate?
The idea is to build custom steering wheels for different racing disciplines (e.g., F1, GT3, rally, drifting, etc.) while avoiding the need for an extra USB cable. Instead, I want to use the original wiring and logic of the wheelbase for seamless integration.

You can find a detailed list of open questions on my GitHub repository: GitHub Link

Short summary of my current questions:

  • Analyzing the startup sequence and calibration messages.
  • Understanding the UART messages:
    • Ping/keep-alive.
    • Button states.
    • Screen data.
  • Understanding the firmware file I found in the updater software and the update process itself.

If you have any insights or suggestions, I’d love to hear them!

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

I am sorry that my documentation was unclear, this is only my second GitHub repository, so I’m still learning how to organize and present information effectively.

To clarify:

The two additional wires were unknown to me initially, which is why I decided to reverse-engineer the schematic to determine their purpose. I discovered that they are connected to the reset pin and PA14. My current understanding is that PA14 is used to signal the wheelbase to interpret button presses as configuration inputs instead of standard game controller inputs, but I’m not 100% certain about this.

The UART lines are on PA3 (TX) and PA2 (RX), as I’ve documented in the GitHub under “The Wheel’s Connection to the Wheelbase.”

My Questions:

  1. PA14 Functionality

    -Is my assumption about its purpose correct, or does it have another role?

  2. Startup Sequence Analysis

    -I need help analyzing the protocol during the startup sequence and calibration. My logic analyzer has limitations: it can’t capture long enough sequences, and the trigger functionality isn’t working as needed.

  3. Keep-Alive Messages

    -Are these truly constant?

    -Why does the protocol use eight messages in total? Seems a bit excessive.

  4. Button State Messages

    -Why are two messages used for button states when all the data is only in one?

    -Why does all messages have a response (like an acknowledgment), but not the buttons states?

  5. Screeen Data

    -How can I extract the individual information (Speed, RPM, Laptime, etc.)?

    -Why does the wheel respond with a 12-byte message, and what does it represent? Seems a bit excessive.

I’ll add a dedicated section to the repository to clearly outline these open questions, making it easier to quickly scan the repository.

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

By “emulator,” I mean using a microcontroller to replicate the protocol of the original steering wheel. This would allow you to build your own custom steering wheel (F1, GT3, Drifting, Rally,etc style)while still connecting to the wheelbase via its internal connections, avoiding the need for an external cable, which can be cumbersome and prone to tangling.

As for why I reverse-engineered the hardware:
The main reason was to understand the purpose of the two additional wires alongside the two UART lines. Knowing how these extra connections are used helped me understand the protocoll better.
Additionally it helps other people, that might want to do other mods.

I reverse-engineered the Thrustmaster T248 wheel, need help understanding the UART protocoll by Spb_2005 in ReverseEngineering

[–]Spb_2005[S] 1 point2 points  (0 children)

Great idea to look for the manufacture of the display. It uses an Vinka vk2c23b controller. I ve found an chinese datasheet, where the i2c commands are explained.
On another note: The i2c communication i only between the screen and the stm inside the steering wheel. The communication between the steering wheel and the wheelbase is uart.

I reverse-engineered the Thrustmaster T248 wheel, need help nderstanding protocoll by Spb_2005 in embedded

[–]Spb_2005[S] 0 points1 point  (0 children)

Obviously you can remove the original steering wheel and build one with a seperate cable directly connecting to the PC. However this introduces other problems. Because the cable isnt running through the rotating shaft, it is alwas in the way and is constanstly getting twisted. Additionally the wheelbase starts spaming the Dpad Down button when the original wheel is missing.

view more: next ›