Thrustmaster TQS LED
-
@Tomcattwo haven‘t seen any code that does this with target yet. The code I found digging into this did only trigger LEDs depending on button states and press / release cycles without acting on real sim data. But that doesn’t mean much. Just did a short research on GitHub.
Plenty of very talented people here. IMO there are many ways to solve this, directly reading shm, calling an external api toy with arguments and react on return codes (that’s why I mentioned „spawn“)…
My C-foo is very basic too, but it‘s an interesting challenge. That said, my first step is to get TWA react on pressing buttons like it does in the sim. Usually someone with much better programming skills pops up and takes the challenge. I‘d say, @scubapics sounds like he knows how to implement a skeleton or even a proto that has some bells and whistles
-
@scubapics said in Thrustmaster TQS LED:
@r00t said in Thrustmaster TQS LED:
MODE_KEEPENABLED it works just like target isn’t running and preserves the DX button IDs you already know.
Thanks for this. This is a game changer for me as I prefer to use the game/simulation to map buttons and axis to game functions.
This will make the scripting far simpler so that I can focus on just controlling the LED from game output. Not that I really need to as I am a VR flyer only but I am a software system engineer so I like to dabble.
Headers contained a third mode called MODE_FILTERED, no idea what it is actually doing.
-
@r00t said in Thrustmaster TQS LED:
@Tomcattwo haven‘t seen any code that does this with target yet. The code I found digging into this did only trigger LEDs depending on button states and press / release cycles without acting on real sim data. But that doesn’t mean much. Just did a short research on GitHub.
Plenty of very talented people here. IMO there are many ways to solve this, directly reading shm, calling an external api toy with arguments and react on return codes (that’s why I mentioned „spawn“)…
My C-foo is very basic too, but it‘s an interesting challenge. That said, my first step is to get TWA react on pressing buttons like it does in the sim. Usually someone with much better programming skills pops up and takes the challenge. I‘d say, @scubapics sounds like he knows how to implement a skeleton or even a proto that has some bells and whistles
Well… funny you should say that. I am looking at it… but for DCS at the moment. I expect any code I write will be transferrable to BMS with a translation layer/wrapper to convert BMS output to a format readable by my code/script.
-
@scubapics don’t know if you already stumpled this, but there is a tcp/udp socket server according to hid.tmh. Couldn’t find any additional documentation, tho. I launched a script, it binds to the socket and listens for connections.
//Creates a server on the specified port to process external data //port - the port number used by the server //useUDP - 0(default) to use TCP protocol, 1 for UDP datagrams //interface - 0(default) to install the server on the local interfaces, // a string IP address to use the corresponding interface only //NOTE: TCP needs 2Bytes at the start of each frame indicating the size of the packet ( 2 + size of data that will follow) // this information will not be passed to the callback, but it is needed to separate the frame from the stream // (the size info can be added to the data buffer or with a separate call, before sending the data) // UDP sends the whole packet in one chunk, no extra size information is needed // maximum data size is limited to 4096Bytes int InitSocketServer(int port, int useUDP=0, int interface=0){}
This frozen Elite Dangerous Warthog github project has some bits and pieces that puts extracted game data from ED into json, and push this via the socket to the device.
This ED project was forked / evolved to this one which at got rid of the tcp socket implementation in more recent versions and use 500ms polling on it’s status file and push data to the device. Didn’t follow the code on how it then proceeds with changing stuff on the device, tho. But it looks promising Just wanted to heads up in case you get stuck somewhere.
-
Thank you for this profile, any ideas on how to make the “Programmable LED display” panel lights" work?
Thank You.
-
@ViperDriver if “Programmable LED display” refers to LED4 to LED13 on the ViperTQS:
a) see https://forum.falcon-bms.com/post/383845. This post outlines how it generally works in T.A.R.G.E.T. GUI. You need to create a press or release trigger from a button and enable/disable the LED of choice. T.A.R.G.E.T. GUI is kind of limited in various aspects (e.g. merging everything into one virtual adapter which may result in the need to re-map keys).
b) The TM T.A.R.G.E.T. script editor is the alternative way of getting this done. It’s much more powerful and eleminates the problem of merging joysticks, with the drawback that it’s C-code based, not GUI based. Basic understanding of C and a bit of reading the TM docs are needed to get things done there. I posted simple example here: https://forum.falcon-bms.com/post/385207. It’s using a two "CHAIN"s of commands (on/off 4 LEDs at once) as a "SEQ"ence (1st chain is triggered on 1st press, 2nd chain is triggered on 2nd press).
I’m currently playing around with the TM script editor to mimic the TWA stuff. My current code is the most ugly code in the world and hurts the eyes of knowledgable people… besides that, it is able to
- toggle all TWA LEDs on/off with POWER button
- ALTITUDE starts with red LED on and toggles red/green on each press
- SEARCH is steady ON by default and toggles endless flash loop/steady on press, if POWER is toggled, it preserves flash/steady state
The SEARCH button sometimes ends-up in a wrong state, And sometimes interruptions by other presses seem to result in unwanted states of LEDs.
Gear LEDs and Gear Handle LED doesn’t have any dependency to each other (at least as long as there is no sim data readout). Implementation is straight forward. It’s on as long as Gear moves (error conditions aside).
Currently there is no real sim data interaction…but hamsters may be working already… some ideas where thrown around here.
But back to the LED4 to LED13: what yould you like to do with them? When should they be on or of - considering that there is no interaction between the sim and the TQS. It must be something you trigger on the device for the time being.
-
I have this mostly working with DCS.
-
I’ve asked TM for a SDK or API to create an interaction tool linked to F4ShareMemory. No answer yet.
If someone know how to sniff out “usb communication” to build a driver’s overlay, you’d make me happy ! -
@benco said in Thrustmaster TQS LED:
I’ve asked TM for a SDK or API to create an interaction tool linked to F4ShareMemory. No answer yet.
If someone know how to sniff out “usb communication” to build a driver’s overlay, you’d make me happy !Good luck with getting anything from Thrustmaster.
I have no experience of F4ShareMemory… yet. If were to (probably will) do it, I would create an app to get what you need from F4ShareMemory and write it to a file or to a TCP socket.
Target can read a file or handle TCP packet events.
-
@benco USB should be serial communication, right? So that might actually be relatively easy to reverse engineer. I’d love to help, but don’t have a TQS. Maybe try using Wireshark?
@scubapics I’ve used F4SharedMem now for two projects: the Virtual Crew Chief in VoiceAttack and to drive the panels of my simpit. Let me know if I can help with the shared memory part of the project.
-
@Ricky I’ve pretty much got it sorted. I’ll probably have it finished in a day or so with a fair wind.
-
@scubapics
Really looking forward to this! Thank you for taking on this project!
Regards,
Tomcattwo
(VoiceClone) -
@Tomcattwo wait no more. It is done.
The solution consists of Thrustmaster TARGET scripts and an executable called BMS2Target.exe.
BMS2Target.exe is a console application for 64bit Windows. I have not built a 32bit version and I would expect 99.99% of users will not be on Windows XP!
BMS2Target.exe reads the Falcon BMS shared memory and sends the relevant lamp data to the Thrustmaster TARGET software that is running the ViperTQSLEDSync.tmc script. The data is sent via TCP. Packets are only sent if the data changes and the script handles the packet through an event. Thus it is fairly efficient.
The BMS2Target.exe reads the Falcon shared memory every 100ms (0.1 seconds). Not too taxing on the system yet fast enough so that we humans won’t notice any lag.
Copy BMS2Target.exe to anywhere you like on your PC. Copy ViperTQSLEDSync.tmc wherever you keep your TARGET scripts.
If you are using a TARGET script to configure your ViperTQS, you’ll have to figure out how to merge ViperTQSLEDSync.tmc and your script yourself. Also don’t expect any support if you modify or merge ViperTQSLEDSync.tmc with your own. Ideally, you should be using the Alternative Launcher to map your ViperTQS to Falcon BMS.
You can run BMS2Target.exe before or after starting Thrustmaster Target and launching ViperTQSLEDSync.tmc script and also before or after starting BMS.
Give it a whizz. I’ve done basic testing. There is bound to be some fine-tuning to do. So let me know how you get on.
Oh, one more thing. The Threat Warning AUX lamps on the TQS have their limitations. The ACT/PWR switch has only one LED, not two as per the simulation. So I have programmed it to be off when there is no activity and on when there is. The ALTITUDE switch has two LEDs but they both illuminate the whole switch! One is red and one is green. So I have programmed it to be red when LOW is activated and green when LOW is not activated.
You can get the files from here:
https://forum.falcon-bms.com/topic/26193/bms-to-thrustmaster-vipertqs-led-controller
-
@scubapics
Fantastic Work! Based on this, I will disable Win 11 Core Memory Integrity and install TARGET Software and give it a spin! Thank you for the great work on this. Will let you know if I run into any issues.
Regards,
Tomcattwo
(VoiceClone) -
@scubapics ,
Now for the Speedbrake!F4SharedMem variable for SpeedBrake is:
CurrentFlightData.speedBrake
and it apparently reads speed brake position form 0 to 1, 0 being fully closed and 1 being 60 degrees open.
So if we can set BMS2Target to read speedBrake position = 0.2, 0.4, 0.6, 0.8 and 1.0, we can get the LEDs for speedbrakes programmed in the script to respond. Would need to code it to toggle light on if off and off if on when the changes occur.Also, is it possible to have BMS2Target work for any Block of F-16? Don’t know if that is a hard to do or easy to do…
Regards,
TC2 -
@Tomcattwo said in Thrustmaster TQS LED:
@scubapics ,
Now for the Speedbrake!F4SharedMem variable for SpeedBrake is:
CurrentFlightData.speedBrake
and it apparently reads speed brake position form 0 to 1, 0 being fully closed and 1 being 60 degrees open.
So if we can set BMS2Target to read speedBrake position = 0.2, 0.4, 0.6, 0.8 and 1.0, we can get the LEDs for speedbrakes programmed in the script to respond. Would need to code it to toggle light on if off and off if on when the changes occur.Also, is it possible to have BMS2Target work for any Block of F-16? Don’t know if that is a hard to do or easy to do…
Regards,
TC2You don’t ask for much
Speedbrake is a good idea. Someone else on DCS asked if they could be on when locked on by radar and flashing while missile warning is on.
As for other blocks… anything is possible if it is supported in the shared memory.
-
@benco Can we still use the Alt Launcher key mapping in conjuction with this? Last time I tried Target, it overroad Alt Launcher.
-
@MailMan The buttons of the TQS aren’t merged into the Thrustmaster Virtual Game Controller. This is achieved through the “MODE_KEEPENABLED” flag in ViperTQSLEDSync.tmc for the TQS (or ButtonBox if you add this one). The Alt Launcher just sees everything like if T.A.R.G.E.T. isn’t running.
-
@MailMan said in Thrustmaster TQS LED:
@benco Can we still use the Alt Launcher key mapping in conjuction with this? Last time I tried Target, it overroad Alt Launcher.
Yes
-
@r00t Man could you send your profile worging al leds a without problem wtih BMS?