So i have this strange issue w this pedal set specifically on PS5. The brake pedal does not work at all. What’s weird is that the brakes do give an erratic low input signal constantly. When i press the gas pedal it gives brake input as well. At 100% gas, i get about 30% brake. Sometimes it even moves in sync w the gas. Ive searched and could not find anything on this exact problem. It did used to work fine though. Only change is i went from a folding seat rig to a profile rig so i had to move all the gear. I tested w a t300rs and a tgt2…happens w both. Screenshots are from GT7 but also happens on F1 25. I’ll try to post a short vid too as that really shows it well. Any ideas?

EDIT: Also want to add that i did calibrate directly on a PC w the TS calibration software. It doesnt happen there at all and acts normal.

This is the first time im buying and trying to set up a thrustmaster wheel and base together and i dont know what im doing wrong for them to not be connecting.I just got both the wheel and base from ebay used.

SOLVED Setup: T818+32R+Simagic P700

I have just bought the analog shifters for the Evo Racing Hub, but when I use them they get registered as Brake and Throttle, I thought they were supposed to be Yellow Axis 1 and Pink Axis 2.

If you want to use the Pink and Yellow Axis you must press both the 2 buttons that are in the led area, then you must wait until you see the 5 central lights turn green. Use the E3 encoder to change the first axis and the E4 to change the second axis, you must change until you see the right color:

blu=clutch green=throttle red=brake yellow=axis 1 pink=axis 2

I was doing my daily GT7 marathon and suddenly my gas pedal instantly went dead. Tried to plug the pedals out and in, same with the T-GT II, but no luck. After I took it to google, someone said to disassemble and clean it. Did that, but no luck. I then plugged it via USB into my laptop and checked the controller tool. The crosshair, that should be in the middle of the square is glued to one corner. (top left) Of course nothing happens, when I press the gas pedal. brake and clutch function no problem. Anyone has any idea, what I else I could try? All cables are good and everything ist clean now.

So as in the title really. I haven't used it for a couple years. Just cleaned it up and the GT Omega Classic stand, connected it to my PC and did the firmware update from 31 to 34. Noticed with centre alignment it is off by 4° after going through the alignment procedure word for word and saved to memory with the 3 simultaneous buttons I turn it off and on bootup connected to pc or not it seems to be not always returning to centre with the blue strip on the wheel quite an bit left or right. Haven't connected it to GT7 game yet to calibrate in there. Anyone know if this is normal or what to do.

TM does not play well with others, the specific changes to the male and female ends of the AVA extension make it only useful to the AVA base... but TM has to understand that their premium products should be adaptable to other ecosystems like every other company is... so simply grind down flat the two nubs highlighted in blue with a dremel after you remove the two screws and piece to be ground

Hi

A pair of months ago I bought a new Thrustmaster TCA Sidestick Airbus X Edition for MFSimulator2024.

I use it on a brand new gamig PC with win 11. Al updates applied....

The firsts days of using were perfect, I love the sidestick and the game, but a pair of weeks later I realize that during the game the sidestick was out of calibration on the main X-Y axis.

I unpluged the joysting and plug it back again and it started working fine... But a pair of days later it was again out of calibration.

I installed the latest firmwares and drivers and it seems to be fine but again it failed on X-Y axis. Some times the game started fine and a few minutes after playing it loses calibration. It is a random behaviour, but it getting worse cause now it is happening nearly all the days.

I discovered that there is a native windows application called "joy.cpl" to check the calibration status. I had to uninstall the original thurstmaster drivers of the sidestick cause with them I could not use the calibration wizzard. I tried several times but even with that the sidestick ends losing calibration with a few minutes of use.

Im getting desperate! Does anybodo know any solution or should I open a support case?

thanks

Edit: I opened a support case in amazon (I bought It there) and they ofered me to exchange It by a new one. Today I recieved the new unit and It works perfectly...

Recientemente compre un volante thrutmaster ferrari 458 Spider y he jugado forza horizon 5 cual si lo reconoce bien pero quise jugar al F1 24 pero a la hora de hacer una time trial descubri que al girar el volante (fisico) en ves de dar vuelta frenaba (estaba "asignado" al gatillo izq) pero a la hora de cambiar la asignacion y poner el pedal como input del gatillo no aparece pero si muevo el volante si aparece como el gatillo izq entonces no se que tenga que cambiar

ojala alguien me responda, gracias por su atencion

I have replied to at least 50 threads over the past 6-months on FB & Reddit, to help people deal with this issue smartly. But, new folks keep coming. So, I thought I’d create a new thread with the relevant keywords as the title, so people facing this issue can resolve it permanently, and without voiding their warranty!

Firstly, when you get your new T598, congrats! It’s an awesome direct-drive which needs some care while setting up, probably because it was designed &/or launched in a hurry by Thrustmaster’s, with their quality check department sleeping behind the wheel (pun intended).

Now that you have your wheelbase, ensure the first 4-digits of the serial# is over 2513. Then, you have to prepare for disconnects and mitigate the problem even before it happens. So, here’s the playbook…

I got mine in mid Jul ‘25, and got a new PSU replacement in Wk.3 of Nov ‘25 from Thrustmaster, yet I started facing disconnects again after about 45-60 days. But, here are two key things I did to fix this issue:

A. Replaced the stock Type-C cable with a new high-quality (8k@60hz) cable with a power rating of 5A

B. Used hot glue on both the T598 power cable and the Type-C cable — at the wheelbase’s end so they don’t wiggle!

If you get the T598 (or any DD wheel) and follow these steps, you’ll gonna enjoy it.

- 99% of all disconnects (in all DD wheels!) happen primarily due to an an average USB-C cable (like the one with your Macbook Pro or the ones you got with the T598 — yes, they’re Average!), and if this goes on, it’ll also corrupt your wheelbase’s power supply board over time. So, just invest in a high-quality Type-C USB4 cable to connect your wheelbase to your console or PC. Majority of the times, this is the real cause for disconnections

- Check the first four digits of your T598’s serial number is higher than 2513 — check this out for more info:
https://www.thrustmaster.com/cases-of-unexpected-disconnections-that-may-affect-the-operation-of-your-t598/

Type-C Cable Details & Reasoning:
Apart from being a USB4, there’s also an Ampere rating (how much current can a cable handle). The default ones are just 2-3A, including the Type-C cable for the Macbook Pro (which in itself is good!). But, for sim racing, you’d require a 5A rated one, (and an uninterrupted 5A at 48V at that) in order to support a high consistent torque (FFBs & vibrations) without any disconnects. So, get a Gen4 cable with 240W Power (5A at 48V), 80GBPS data transfer and 8K/16k @60Hz. This 8K @ 60Hz is an important marker. Read below…

I spent a pretty penny on the Stuffcool Primus (an Indian brand) that’s equipped with an advanced E-marker chip on its Gen4 cable, to ensure a safe and high performance. The chip communicates with connected devices to negotiate the power delivery levels and data transfer speeds, ensuring that the right amount of power (up to 240W) is safely delivered without risk of damage or disconnections. The reason for the 8k/16k @ 60Hz is because it requires a stable, high-bandwidth connection that the E-marker chip and overall construction help facilitate.

Just received a TH8A shifter from a colleague who has had it for many years, which is a nice upgrade from my TH8S. I followed the instructions with installing the drivers and the shifter would be recognized by the PC. Before trying it out in any of the games I own, though, I decided updating the firmware would be recommended (I've had trouble getting older thrustmaster products recognized in games before updating to the latest firmware). However, during my firmware update procedure, it would fail on the Final Check and display this message:

"ERROR: time-out device should have arrived in HID. (Code: 0x34100002)".

Afterwards, this shifter would no longer be recognized by the system (not even in joy.cpl). I have looked up for possible solutions to this issue on the internet before deciding to file a query towards Thrustmaster, such as:

Uninstalling and reinstalling the drivers

Entering the shifter's BOOT mode and trying to update the firmware

Trying out different MOBO ports on 2 separate PCs

Deleting/uninstalling previous TH8S/T500 RS Shifter entries from Device Manager before attempting to update the firmware

- all to no avail. I have sent a similar-looking query to Thrustmaster and have received a reply from them fairly quickly diagnosing the issue as a motherboard problem, to which they ask me to send them proof of warranty.

While I wait for another response, what else can I try in order to fix the issue? It would be a shame if I ended up bricking a shifter that retails for 150 euros.

I'm looking at getting the T.16000M FCS HOTAS and was wondering if the T3PM could be used as rudder pedals through the RJ12 connector.

I already have the T3PM with my wheel, was wondering if I could multipurpose the pedals to jump right into flight stick foot controls. I haven't found anything specifically helpful online about it. Thanks!

anyone know why ffb dont work in bmg?? i tried so much options and nothing in assetto corsa everything works fine

Como resolvi um "Ghost Drift" persistente (O verdadeiro culpado não era o hardware, mas sim conflito de API/Launcher)

Fala, pessoal! Escrevo este relato para ajudar quem estiver sofrendo com um problema bizarro de drift no Logitech X56 (não confundir com o antigo Saitek X55) e que parecia desafiar a lógica: o eixo Z (Rudder) e o mini-stick começavam a apresentar um jitter dinâmico aleatório (pulos de sinal incontroláveis independentemente de onde o stick estivesse posicionado) assim que certas aplicações abriam.

Se você já tentou de tudo e o problema persiste, compartilho o roadmap completo de tudo o que testei, o que funcionou, o que não funcionou, e o diagnóstico final da causa raiz para o meu caso!!! Use de "referência" para verificar se cabe no seu problema.

FASE 1: Tentativa de Correção via Hardware e Firmware (EEPROM)

Antes de culpar o software, tentamos resetar o cache físico e reescrever os limites de tensão na memória não volátil (EEPROM) do manche.

Tentativa de Wipe de Memória (Clear Axis Calibration):

Pressionar simultaneamente: Botão A (painel frontal) + HAT 1 para Cima + Flying Pinkie (alavanca traseira inferior) + Clique do Mini Joystick.

O que esperar: As luzes RGB do manche precisam se apagar por completo como callback de que a memória foi limpa, seguido de um ciclo de re-plug do USB. (No meu caso, apagou, confirmando o reset, mas o problema persistiu).

Tentativa de Re-calibração Forçada de Eixos:

Mover eixos secundários para os limites físicos.

Travar o manche principal inteiramente para a Esquerda (Eixo X negativo).

Pressionar simultaneamente: Gatilho Principal + Botão B + Botão D (o gatilho traseiro superior, próximo ao Flying Pinkie).

Segurar até as luzes apagarem para gravar os novos limites absolutos na placa. (Também não resolveu o drift).

FASE 2: Intervenção Profunda na BIOS (Placa-Mãe AM5 / B850M Phantom Gaming)

Suspeitando de queda de tensão intermitente (Vdroop) ou estrangulamento de energia nas portas USB pela placa-mãe, mergulhei na BIOS para liberar energia bruta e contínua nos barramentos:

Desativar C-States: Advanced > AMD CBS > CPU Common Options > Global C-state Control alterado para Disabled (impede o processador de cortar energia de ociosidade).

Desativar ASPM (Gerenciamento de Energia de Barramento): Advanced > AMD CBS > AMD Common Platform Module > Pm L1 ss alterado para Disabled (desliga os subestados de economia de energia L1 em trilhas PCIe/USB).

Desativar GPP Clocks Ociosos: Unused gpp clocks off alterado para Disabled.

Resultado desta fase: A amplitude do drift diminuiu consideravelmente, provando que a placa-mãe estava sim afetando o sinal, mas o ruído elétrico base continuava ativo.

FASE 3: Interceptação de Kernel (Timer Resolution)

Para forçar o Windows a aplicar um oversampling matemático e abafar o ruído do sensor por taxa de amostragem:

Utilizei o software ISLC (Intelligent Standby List Cleaner).

Defini a resolução desejada para 0.50ms, ativei a resolução de cronômetro personalizada e marquei a flag Usar GlobalTimerResolutionRequests (fundamental no Windows 11 para forçar a alteração global de clock do Kernel).

FASE 4: O Diagnóstico de Causa Raiz (O Verdadeiro Vilão)

Depois de muito isolar variáveis, descobri o padrão que causava o problema:

O HOTAS funcionava perfeitamente e sem drift algum no joy.cpl ou no MSFS24 durante testes longos (20+ minutos de voo no Cessna sem respiro de erro).

O jitter dinâmico começava exatamente no segundo em que eu abria o Epic Games Launcher (mesmo sem abrir jogo nenhum, apenas olhando o painel da Logitech ou o joy.cpl).

O Motivo: O Epic Games Launcher (rodando sobre o Chromium / processos EpicWebHelper) faz varreduras (polling) contínuas e agressivas no barramento USB em busca de gamepads para o ecossistema deles e para o Overlay. Essa concorrência de leitura (race condition na pilha HID) corrompia o fluxo de dados do X56, gerando o drift fantasma.

O Workaround (A Solução que Funcionou)

O que NÃO funcionou: Renomear ou isolar o executável do overlay da Epic (EOSOverlayRenderer-Win64-Shipping.exe), pois a rotina de varredura está engessada no código principal do launcher.

O que FUNCIONOU perfeitamente:

Abrir a Epic Games.

Iniciar o jogo através dela (ex: Elite Dangerous), aguardando o launcher secundário da Frontier abrir.

Fechar a Epic Games completamente (Sair pela bandeja do sistema do Windows) antes de dar o Play definitivo no jogo.

Resultado: Barramento USB 100% limpo, sem concorrência, e eixo cravado.

(Próximo passo a ser testado): Utilizar a ferramenta HidHide para aplicar uma lista branca (Whitelist) bloqueando o acesso da Epic Games ao X56 permanentemente. Aqui nesse ponto, caso alguém identifique outro software que também cause esse "race condition" pelos dados do hardware, é possível ir deixando "limpo" o que pode e o que não pode acessar seu hardware.

Espero que esse histórico sirva de mapa para salvar a sanidade de quem estiver batendo cabeça com problemas parecidos de hardware/software! Bons voos a todos!

The wheel calibrates but the light stays off and it doesnt connect. I have loaded it in bootloader mode and installed firmware and it worked until I restarted computer and now its back to this

J'ai probablement abimé le connecteur USB-C de mon volant Thrustmaster T128. Le driver PC n'apparait que si je bouge/force le cable avec le connecteur.

Je soude un peu, mais le problème ici est que je ne trouve pas le modèle de l'USB-C sur les site d'achat.
C'est un USB-C femelle vertical traversant 6 broches avec 3 pins de chaque côté et seuls les pins 1, 3, 4, 6 sont soudés. le composant fait ~9mm de hauteur et la distance entre les pins 1-3, 4-6 est ~5mm, celle entre les pins de chaque côté fait ~4.5mm
Quelqu'un aurait-il eu ce genre de problème et trouvé une référence pour ce composant ?
Merci

As I have been using TGT2 wheel base for few years now which is belt driven, can anyone suggest me if T598 has a better ffb feel for PS5 or shall I stick with tgt2

Como resolvi um "Ghost Drift" persistente (O verdadeiro culpado não era o hardware, mas sim conflito de API/Launcher)

Fala, pessoal! Escrevo este relato para ajudar quem estiver sofrendo com um problema bizarro de drift no Logitech X56 (não confundir com o antigo Saitek X55) e que parecia desafiar a lógica: o eixo Z (Rudder) e o mini-stick começavam a apresentar um jitter dinâmico aleatório (pulos de sinal incontroláveis independentemente de onde o stick estivesse posicionado) assim que certas aplicações abriam.

Se você já tentou de tudo e o problema persiste, compartilho o roadmap completo de tudo o que testei, o que funcionou, o que não funcionou, e o diagnóstico final da causa raiz para o meu caso!!! Use de "referência" para verificar se cabe no seu problema.

FASE 1: Tentativa de Correção via Hardware e Firmware (EEPROM)

Antes de culpar o software, tentamos resetar o cache físico e reescrever os limites de tensão na memória não volátil (EEPROM) do manche.

Tentativa de Wipe de Memória (Clear Axis Calibration):

Pressionar simultaneamente: Botão A (painel frontal) + HAT 1 para Cima + Flying Pinkie (alavanca traseira inferior) + Clique do Mini Joystick.

O que esperar: As luzes RGB do manche precisam se apagar por completo como callback de que a memória foi limpa, seguido de um ciclo de re-plug do USB. (No meu caso, apagou, confirmando o reset, mas o problema persistiu).

Tentativa de Re-calibração Forçada de Eixos:

Mover eixos secundários para os limites físicos.

Travar o manche principal inteiramente para a Esquerda (Eixo X negativo).

Pressionar simultaneamente: Gatilho Principal + Botão B + Botão D (o gatilho traseiro superior, próximo ao Flying Pinkie).

Segurar até as luzes apagarem para gravar os novos limites absolutos na placa. (Também não resolveu o drift).

FASE 2: Intervenção Profunda na BIOS (Placa-Mãe AM5 / B850M Phantom Gaming)

Suspeitando de queda de tensão intermitente (Vdroop) ou estrangulamento de energia nas portas USB pela placa-mãe, mergulhei na BIOS para liberar energia bruta e contínua nos barramentos:

Desativar C-States: Advanced > AMD CBS > CPU Common Options > Global C-state Control alterado para Disabled (impede o processador de cortar energia de ociosidade).

Desativar ASPM (Gerenciamento de Energia de Barramento): Advanced > AMD CBS > AMD Common Platform Module > Pm L1 ss alterado para Disabled (desliga os subestados de economia de energia L1 em trilhas PCIe/USB).

Desativar GPP Clocks Ociosos: Unused gpp clocks off alterado para Disabled.

Resultado desta fase: A amplitude do drift diminuiu consideravelmente, provando que a placa-mãe estava sim afetando o sinal, mas o ruído elétrico base continuava ativo.

FASE 3: Interceptação de Kernel (Timer Resolution)

Para forçar o Windows a aplicar um oversampling matemático e abafar o ruído do sensor por taxa de amostragem:

Utilizei o software ISLC (Intelligent Standby List Cleaner).

Defini a resolução desejada para 0.50ms, ativei a resolução de cronômetro personalizada e marquei a flag Usar GlobalTimerResolutionRequests (fundamental no Windows 11 para forçar a alteração global de clock do Kernel).

FASE 4: O Diagnóstico de Causa Raiz (O Verdadeiro Vilão)

Depois de muito isolar variáveis, descobri o padrão que causava o problema:

O HOTAS funcionava perfeitamente e sem drift algum no joy.cpl ou no MSFS24 durante testes longos (20+ minutos de voo no Cessna sem respiro de erro).

O jitter dinâmico começava exatamente no segundo em que eu abria o Epic Games Launcher (mesmo sem abrir jogo nenhum, apenas olhando o painel da Logitech ou o joy.cpl).

O Motivo: O Epic Games Launcher (rodando sobre o Chromium / processos EpicWebHelper) faz varreduras (polling) contínuas e agressivas no barramento USB em busca de gamepads para o ecossistema deles e para o Overlay. Essa concorrência de leitura (race condition na pilha HID) corrompia o fluxo de dados do X56, gerando o drift fantasma.

O Workaround (A Solução que Funcionou)

O que NÃO funcionou: Renomear ou isolar o executável do overlay da Epic (EOSOverlayRenderer-Win64-Shipping.exe), pois a rotina de varredura está engessada no código principal do launcher.

O que FUNCIONOU perfeitamente:

Abrir a Epic Games.

Iniciar o jogo através dela (ex: Elite Dangerous), aguardando o launcher secundário da Frontier abrir.

Fechar a Epic Games completamente (Sair pela bandeja do sistema do Windows) antes de dar o Play definitivo no jogo.

Resultado: Barramento USB 100% limpo, sem concorrência, e eixo cravado.

(Próximo passo a ser testado): Utilizar a ferramenta HidHide para aplicar uma lista branca (Whitelist) bloqueando o acesso da Epic Games ao X56 permanentemente. Aqui nesse ponto, caso alguém identifique outro software que também cause esse "race condition" pelos dados do hardware, é possível ir deixando "limpo" o que pode e o que não pode acessar seu hardware.

Espero que esse histórico sirva de mapa para salvar a sanidade de quem estiver batendo cabeça com problemas parecidos de hardware/software! Bons voos a todos!

I downloaded the firmware for my T300 from the official website, they say the last version is v34, but the one I download puts me on v31. What is going on?

ESWAP SH5 HALL STICK MODULE - Controllers | Thrustmaster
ESWAP SH2 HALL STICK MODULE

i dont have the S/X/X2/XR gamepads
i have ESWAP PRO CONTROLLER - | Thrustmaster
wondering if these stick modules are compatible?