Jump to content

Drakoz

Members
  • Posts

    266
  • Joined

  • Last visited

Everything posted by Drakoz

  1. Yes, it is possible for TARGET and DCS BIOS to talk to each other, but it requires custom programming in TARGET, and maybe using a helper app outside of TARGET to parse the data from DCS BIOS for TARGET. You might be able to do this using data files, or maybe using sockets. But it requires some knowledge about programming. If I remember correctly, DCS BIOS exports data to a file and you parse the file with a custom program to read data from DCS or write data to DCS. TARGET is a C language interpreter and can do most of what C can do including read files on your harddisk, or even send/receive network packets on a network using sockets. The problem is, TARGET lacks any kind of proper string handling functions. TARGET handles numbers fine, but strings (arrays of char) do not work properly in TARGET compared to C mostly because TARGET does not understand the \0 end of string nul (and does not have a full set of string handler functions). If DCS BIOS exports data to a file in a complex way (using words, strings, or more than just numbers), it is more complicated for TARGET to parses the file, but still possible. But it may be better to write an external program to take the DCS BIOS data and convert it (in real time) to a second file for TARGET to use in the form of straight numbers (integers). Another way to communicate with TARGET is to open a socket in TARGET. A socket is a network interface between one program and another, but sockets can be used between programs on the same computer. TARGET supports sockets, but it is not documented. There are a few examples how to do it on this forum or on elsewhere, but will take some searching. Only 3 or 4 people I am aware of have actually used sockets in TARGET in a working example. I have considered it, but never actually tried. DCS BIOS is perfect for using a socket. Meaning, if DCS BIOS doesn't already support sockets, someone has probably created a socket interface for DCS BIOS for a DIY controller. If so, maybe you could use that as a starting point to create a socket interface between DCS BIOS and TARGET. It would be more efficient for an external helper app to parse the DCS BIOS information and send TARGET only the data you want. I have seen some other examples of DCS BIOS wrappers or helper apps that send status information to a joystick in order to turn LEDs on and off. Somewhere on the DCS fourms, I believe there is one created for the Logitech G940 throttle button LEDs. Anyway, for someone that is savvy with programming, it is possible to use DCS BIOS to talk to TARGET and vice versa.
  2. I just posted a comment on the above thread about dropping the USB voltage to make a non-working Warthog work. It is very uncommon that dropping the voltage to a power supply would make something work, but I have questions and suggestions in the other thread as to what might be happening. Not solutions, though, as the issue is definitely something wrong with the Warthog.
  3. When the Warthog fails like this, does it show no sign of life when plugged in? Or does it fail a few seconds or a minute after being plugged in? Signs of life could include LEDs lighting up, Windows making the USB boo-beep sound when a USB device is plugged in, etc.? If I were to guess, something is shorting out, but not a hard short. It is probably something drawing more current than it should and the main power supply on the board is shutting off as part of an over current or thermal over run shut down. By lowering the voltage to the USB connector, it may reduce the current or heat enough so the power supply does not shut down anymore. So the problem could be something drawing excessive current, or the power supply itself is having issues at 5.0V, but not at 4.5V or so. If it is an over current, it could be just about anything. For this to happen at 5.0V and not at 4.5V, the power supply has to be right on the edge of thermal or over current shut down. So even a 10mA difference could push it over the edge. It would be interesting to see measurements on the USB connector for voltage and current using one of those USB voltage/watt meters that plugs inline. Comparing the current draw from a working Warthog to a non-working Warthog may be very informative. I'll try mine out and see what the current draw is. I have two of them, and both work normally. Watching the voltage/current throughout the process of plugging it into a hub over time would be very informative as the Warthog tries to startup and negotiate with the hub. Or maybe it doesn't do anything and just fails, in which case the voltage/current should be stable throughout. If the power supply is shutting down due to overcurrent or thermal shut down, the current would drop to nearly 0 mA. That is the detail I am looking for.
  4. I leave the tape on mine always, so yes, it is OK to power it up with the tape in place. The G940 uses hall effect sensors and self calibrates. Or at least I have never had to calibrate it.
  5. It is likely one of the parameters you passed into MapKeyIOUMD() is the issue, not the target.tmh file. What does your code look like?
  6. The G940 notchy gear feel is OK, but not the best. I tend to set the force just strong enough to hold the stick for trim on an aircraft but not so much that it feels really notchy. What is important is how well the stick holds itself without any play. Unfortunately the G940 is pretty bad on that. fred41's firmware helps, and the mods I did to mine to tighten it up also helped a lot, but still has a little too much play to just let it go hands free sometime. The Microsoft Sidewinder Forcefeedback 2 has the best feel of any FFB stick I have used (at least for a consumer grade stick - there are a couple really expensive ones out there I haven't tried). Sadly, the FFB2 doesn't have enough buttons, and worse, it has as dead zone at stick center (not force center, but stick center) that makes it much less desirable for helicopters. It is not so bad for fixed wing, but still annoying. Force center is where the stick is being held, which might not be stick center. If the deadzone moved with the force center, it wouldn't be so bad, but if you trim the stick off center (which is going to happen all the time), you may move through the stick center and have a momentary pause as you move through the dead zone. There is no way to completely disable this deadzone, even using the MS FFB2 software. When powered off, it is OK to let it just flop over. There are no springs in the stick. It is entirely controlled by motors and gears, so it doesn't care what position it is in. What is important is, if you bypass the hand sensor (like putting a piece of tape across the sensor holes), so that the stick force is working even if you let go of the stick, make sure you don't leave it unattended whole powered on. A little noise in the feedback loop, or say, if a cat a person knocked it, can cause it to go into undamped oscillation and beat itself to pieces. They include the hand sensor to prevent it from moving when someone isn't using the stick but it defeats much of the purpose of trimming - so you can let go of the stick for a moment. Most sticks have a optical sensor that your hand covers up. Just put a piece of tape over the sensor holes, and it keeps the stick active even if you let go. Also, you can pull the power plug and still use it on USB as a springless stick. I never do that, but just saying it won't hurt anything. The USB circuit is powered by the USB cable. The power plug only powers the FFB circuit and motors. Yes, after using FFB, I can't go back to a normal stick. I thought I heard the patents have finally expired for the FFB haptic feedback stuff (the software portion of the FFB standard). If so, I hope that means we will finally see some serious flight sim FFB sticks being made. I have threatened to make my own for years as a DIY, but just don't have time.
  7. Never heard of disabling core isolation. I'll check that on my system. If this is a Windows 11 vs. 10 issue, this might be important to know. I have several joysticks, but for helicopters I hate flying without FFB. Very glad to hear you got it working.
  8. Are you running the Logitech Gaming Software v5.10.127? What OS? If you are using Windows 11, or maybe even the latest version of Win 10, there might not be very many people that have tried it with that setup. I'm on Windows 10 21H1 (the early 2021 update) and it works there. There is a 21H2 (most current Windows 10) which I am about to upgrade to so I can verify that. But chances are, if it isn't working, it is something with your install. Disconnect the G940 and try uninstalling the LGS software and re-installing. Follow closely any instructions about connecting the joystick. Many such installers require the joystick to be disconnected before installing or uninstalling the software. The v5.10.127 LGS software should install the driver. If you still can't get it working, you might want to make sure you don't have any newer versions of Logitech Gaming Software (either LGS or their replacement for LGS). I am reaching here. It shouldn't matter. I run a newer version of LGS along side the G940 LGS version and never had issues, but just a thought to try.
  9. And I just noticed you found much of the above info already and tried the firmware (based on your post to fred41's topic). I will reply there.
  10. A) The G940 is an old product and not supported by any recent (as in the last few years) Logitech software. You need to download the software that is specific to the G940. It should be available on the G940 support page. B) Go to the Logitech Support site, Downloads, and search for the G940. Below I pasted a link to the page. Select Windows 10 and you will see Logitech Gaming Software V5.10.127. This is an old version of the Logitech Gaming Software, and is the last version that supports the G940. I haven't tried it on Windows 11, but it works fine on Windows 10. https://support.logi.com/hc/en-us/articles/360024852233--Downloads-Flight-System-G940 C) The Logitech Gaming Software v5.10.127 can confirm the firmware on your device and also update your device to firmware v1.41. The latest from Logitech is firmware v1.42 which tries to fix the reversal bug (see comments below). This firmware is not available from Logitech directly because it was only released on Logitech's older support forum (now deleted). What you really want, though is fred41's hacked firmware which fixes the reversal bug on all axes properly. I have provided links to all this at the bottom of this message. In summary, though, fred41's firmware makes the G940 work noticeably more smoothly vs. v1.41 or even v1.42, and fixes the reversal bug on all axes, not just the X/Y joystick axis. D) Yes, the notchy feel is typical of the G940. The firmware update fixes this a little by allowing the force feedback to work more smoothly (not be so jumpy), but the gearing and design of the G940 still has a notchy feel. The notchy feel can be improved. Somewhere I thought I wrote a bunch of notes on how to do that, but I can't find that right now. I also started a Youtube video on the subject, but never posted it. I suppose I should just post it. There is some discussion about this in fred41's forum topic. Re: your comment that the old version of LGS didn't work either. Make sure you have downloaded LGS v5.10.127. It should install drivers and everything for the G940. Here are links to the things I mentioned above: My explanation of the G940 Reversal Bug and the v1.42 firmware fix: (my first post talks about fred41's firmware fix with links, but I have copied links below as well) https://forum.dcs.world/topic/189949-logitech-g940-reversal-bug-v142-firmware-update/ Archive.org backup of Logitech's support forums about the v1.42 firmware (and download link): https://web.archive.org/web/20120119090658/http:/forums.logitech.com/t5/PC-Gaming/G940-firmware-1-42-is-now-available/td-p/542496 fred41's forum topic about the G940 - a good read if you want to understand how to get the best use of your G940 - includes his discussion of his firmware hack: https://forum.dcs.world/topic/205420-g940-force-feedback-discussion fred41's firmware download (at github): https://github.com/fred41/G940-firmware-fixes
  11. The burned part appears to be a ferrite bead (labeled FB9 and FB usually indicates a ferrite bead). Ferrite beads should appear as a 0 ohm short as they are intended to pass DC voltage, but act as a resistor for high frequency noise. If you have a multi-meter, measure the resistance across the bead. It should show about 0.2 ohms (where the 0.2 ohms is actually the resistance of your multimeter). If it shows a much higher higher result (like 1-2 ohms to hundreds of ohms or an open circuit), the bead has been damaged. Problem is, the burned ferrite bead is the symptom, not the problem. It just passes current, but there is a short somewhere else, and the FB burned because of excessive current due to a short. Inspect all the wiring that goes to/from that board. Maybe a wire got pinched and frayed, and it is shorting on something, or maybe the component the wiring goes to have a short. Check the resistance of both sides of the FB vs. ground on the board (just the board alone, not powered up). You can use the two electrolytic caps to tell what is ground (the two large black cylindrical parts that say 16V and Samcon). The pin soldered to the large white area is ground. The pin soldered to the non-white area is power (+5V or +3.3V). Anyway, If either side of the ferrite shows 0 ohms to ground, that helps prove there is a short on the board. Then connect the board back to the Warthog and repeat the test. If you didn't get a short before, but now you do, it means the short if off the board. I am guessing, but I believe the blown ferrite is for the power supply ferrite (it passes 5V or 3.3V). I assume this because it looks like it connects to a red wire which is often the color used for power. If I am correct, then one or both sides of the ferrite bead should show a short to the non-white side of the cap on the upper side of the board (the one marked 16V in your picture). If so, that is probably normal. There is also a black wire near the red wire. That is probably ground. If my assumption is correct, the black wire should show a short to the white connection for the electrolytic caps. Anyway, there isn't much on this board that would likely fail in a short. It is much more likely something off the board has shorted (what ever is connected to the 2 white connetors on the right side of the board). But it could also be that one of the wires soldered to the left side of the board is shorted. One other thing to check is, do the electrolytic capacitors show any sign of leaking, or bulging. If they are bulging, you can tell because the top of the cap will look like it is pushing out or expanding. These caps are only about 10 years old, so should be fine, but crappy capacitors can start leaking in 10 years. If they are bulging, they may act as a short circuit for too long (as they charge up) and cause over current on the ferrite as well. Probably not, but it is an easy thing to inspect since bulging is a visual clue. Do some investigation like I suggest and let us know what you find. As for repairing it, it might be best to get a new board from Thrustmaster if you can. But be aware, if you put a new board in, and the short circuit is somewhere else in the Warthog, it will blow the FB on the new board as well. So you need to make sure there is no short elsewhere in the Warthog. If Thrustmaster declines to help with this, it is because a problem like this is not so simple as replacing a single board. So they will likely strongly suggest sending the Warthog back to them. If it is a short circuit on a wire off the board, then if you can find and fix the short, you may get lucky and can just replace the FB and the board may be fine again. If desparate, you can just replace the FB with a piece of wire. The FB is to prevent bad radio emissions. It looks like a 100ohm or 1000ohm resistor to 100MHz frequencies, but looks like a short circuit for low frequencies. So replacing it with a wire does not affect normal operation. But again, you need to find the cause of the short or you will just burn something else up. It is also possible that what ever provides power or a signal to this board (though the FB), was damaged. Again, the FB is just a symptom, but not the problem, and other parts may have been damaged on other boards. You can find those parts by tracing the wires that connect to the FB (like the red wire probably). I hope this helps. Comment back with what you discover and I'll try to help more. But again, I strongly suggest, if you can, to get it repaired by Thrustmaster. Or if there is someone you can send to that does circuit repair. They don't need to understand joysticks to know how to repair this. A Joystick like this is a pretty simple concept for someone that understands electronics. Finally, even for an experienced repair person, they may not be able to find, or repair it without getting a new circuit board from Thrustmaster. Hence why I suggest your best option is to get it repair buy Thrustmaster.
  12. Yes, if they did it, the "TWCS Dual throttle" would be more expensive of course. A TWCS can be bought for about $130, similar to the TCA Airbus and TCA Boeing throttles which have fewer and less complex buttons. I wouldn't be surprised if a Dual TWCS throttle had a price in the range of $150-$180 or maybe more. It is a little too far out of the cheap territory at that price.
  13. There is merit to saying that the TWCS (T.16000M) throttle is the best throttle in its price range, and that would absolutely be true if it was a dual throttle. I often recommend the TWCS throttle to people because of features for the price, but I stop short on that recommendation because it is only a single throttle. So it doesn't work for many applications. The other major issue with it is the stiction, but for the price, for those who can't afford a $300-$400 throttle, the TWCS is a good alternative. I would love it is Thrustmaster made a dual throttle version of the TWCS, but I don't expect it to happen. I also love the TCA Airbus and TCA Boeing Throttles. They have hall effect sensors, good feel to their movement (stiction free, with adjustable friction), better build quality than the TWCS, but they lack the buttons to make them useful for a HOTAS application like what you would use a Warthog Throttle or TWCS. So they too are hard to recommend for serious HOTAS applications. FYI, another good inexpensive option for a decent throttle with lots of buttons (and horizontal movement, not pendulating movement) is the CH Pro Throttle. But again, it is only one throttle, not dual throttle.
  14. Here is a complete script with a couple extra commands to test with. This worked fine for me. I am testing this with the Thrustmaster TARGET Event Tester to see the keyboard commands (it shows press and release times - much better for testing), and for checking for the DX button presses, I used the Windows "Game Controllers" control panel (press the Windows key, type "Game Controllers" and it will list "Set up USB game controllers". Run that tool. Run your script. The controller "Thrustmaster Combined" should show up in the Game Controllers List. Double click on it, and you'll see all the DX buttons. Of course, you can use the TARGET Device Analyzer as well for this. Sometimes Device Analyzer has problems in Windows 10, though, but it worked fine for this script on my system today. Note, any button that is not defined in a TARGET script will send its default DirectX button. But when defined in a MapKey command it will no longer send the default DirectX DX button. Hence why we must define DX13 in the example below. Just FYI if you didn't know. So in the example below, H3R should send DX12 as that is its normal default - I didn't define H3R. But H3U, H3D, and H3L will only send DX13 when commanded. And in the example below, that will only occur with H3D and H3L. If this isn't working in game, try it using the Event Tester, Game Controller control panel, or the TARGET Device Analyzer. It should work. I have often seen people have trouble getting something to work in DCS, but worked fine in external test programs. Then only to discover DCS wasn't configured properly. So simplify your testing. If it doesn't work in DCS right away, use the external test programs. And for sure, you must use CHAIN() to map two commands to a single button. So yes, the following will never work: MapKey(&Joystick, H3D, PULSE+R_SHIFT+'h', DX13); Here is my complete and tested script. include "target.tmh" //program startup int main() { if(Init(&EventHandle)) return 1; // declare the event handler, return on error MapKey(&Joystick, H3D, CHAIN(DX13, PULSE+R_SHIFT+'h')); MapKey(&Joystick, H3U, CHAIN('a', PULSE+R_SHIFT+'h')); MapKey(&Joystick, H3L, DX13); } //event handler int EventHandle(int type, alias o, int x) { DefaultMapping(&o, x); }
  15. You need to use the CHAIN() command like the following: MapKey(&Joystick, H3D, CHAIN(DX13, PULSE+R_SHIFT+'h')); This will press DX13, as well as Pulse R_SHIFT+'h' pretty much simultaneously. DX13 will be held down as long as H3D is held but R_SHIFT+'h' will be momentary. Read up on CHAIN() and using D() in CHAIN() if you want to control delays between when the keys are pressed. You can use D(100), for example between any items in the CHAIN() to cause a 100ms delay.
  16. Correct, Thrustmaster does not discuss anything about how to do this. People figured it out by seeing the TCP socket commands in the hid.tmh file (specifically the InitSocketServer() command). I believe you also need to use LoadLibrary() as shown in the sys.tmh file to load the Windows .DLL library that enables TCP sockets. People that understand TCP sockets on Windows were able to figure it out. I haven't done it myself, but there are a few discussions floating around about how to do it. It is definitely advanced stuff. I mean, with as much as I know about C programming and TARGET, it would still take a lot of trial and error for me to figure it out. Plus you must write an external program to talk to the TARGET TCP socket, which requires knowing how to do Windows programming (using tools like Visual Studio and C#, C++, or Visual Basic) and the Windows TCP Socket layer. I think I have seen a couple examples where people have written simple generic TCP socket programs to send and received data to TARGET (or other programs using TCP Sockets). These simple tools can be used with minimal effort to create a debugging tool to test communication with TCP sockets on TARGET. This is all about using TCP sockets as a method of interprocess communication. That is to say, one of the easiest ways for two programs to talk to each other is using TCP sockets. And since TCP sockets is a networking protocol (as in over Ethernet or WiFi), you can even do it from one computer to another. To talk to a program on the same computer, you access the localhost IP address (127.0.0.1:xxxx) where xxxx is the socket number. To talk to a program on another computer, you use the IP address of that other computer. It could even be an Android, iPhone, Raspberry PI, or even an Arduino as all computers that support networking protocols support TCP sockets. As I said, this very quickly goes way beyond simple C programming, but there are examples out there, not just on TARGET related forums, but many other forums about DIY stuff using TCP sockets. Once you understand TCP sockets on Windows, how to do it in TARGET makes a lot more sense because you realize that TARGET provides the basic commands to needed to load the proper .DLL, and create a server. P.S. I believe there is at least one discussion of using TCP sockets here on the DCS forums, and also I believe one or more examples on the SimHQ.com forums.
  17. The simple C (not C#) application you need is the TARGET Script Editor. It is a C like language, and Thrustmaster included some very powerful functions like importing/exporting data using TCP sockets. All Thrustmaster device axes can be read and reported using simple commands like "position = &Joystick[JOYX]". You can print this info to the TARGET console, write it to a file, or send it to another application using TCP sockets, among other things. This is for reading Thrustmaster device axis data, but you can similarly see and manipulate DirectX axis data since TARGET takes the device axis data and writes it to variables that drive the DirectX axis. The same can be said for all buttons.
  18. Ah, force sensing Cougar. Got it. Nice. When you swapped to the Cougar stick, did you swap &Joystick with &HCougar in your script? And did you remove the Configure(&HCougar,MODE_EXCLUDED); line? Do those two things and it should work, or mostly work (I didn't study your entire script). Perhaps post the version of the script modified to work with your Cougar. Also, I assume you loaded the drivers for your Cougar, right? Just checking all the bases.
  19. Not quite sure what you are asking - what is your goal? To replace the Warthog stick with the Cougar stick? Is this because you only have the FA-18C stick for your Warthog, but want to use the F16C style stick on the Cougar instead? The HOTAS Cougar Joystick (&HCougar) uses the same button names as the Warthog Joystick (&Joystick). The only exception is the Warthog stick has a pushbutton on Hat 4 (H4P) but the Cougar does not if I remember correctly. So if you replace &Joystick with &HCougar, your script should work with the same commands for the Cougar joystick. Is that what you mean? If you are translating Warthog with F18 stick to the Cougar, it is the same - same button names on the Cougar, except I believe the F18 stick has a couple more push buttons on Hat 2 and 3 (H2P and H3P) which are not on the Cougar. If you aren't using the Cougar Throttle, you don't even need to connect it, nor do you need to add any special commands for the Cougar Throttle. Or if you just want the Cougar Joystick and Throttle to work along with the Warthog Stick and Throttle, they work the same except for button/switch differences of course. You just need to add more commands for the Cougar. I hope this helps. If not, please explain what your goal is.
  20. The trim hat (or the top most hat) on the Warthog is the chosen DirectX "Hat" which means by definition, it is an 8-way hat whereas the other hats are treated as independent 4-way switches by default (4 independent switches instead of a treated as a hat). To turn the 8-way hat into 4 independent switches, you need program the up, down, left, right settings directly in your sim or use TARGET. So you need to program the hat positions not as a HAT in game, but as separate switch positions. If DCS can't do that (or do it the way you want), then you can use TARGET (either the TARGET GUI, or the TARGET Script editor) to do it. Using TARGET, if you program only the UP, DOWN, RIGHT, LEFT click positions, the 4 corner positions will not have any effect because they will be disabled. This is because when using TARGET, none of the buttons are configured as DirectX buttons by default. In fact none of them are configured period until you configure them. So the top hat on the Warthog is not configured as the DirectX hat by default.
  21. I was surprised the GUI does not support this feature since it is so useful. I checked and as Frederf said, it is not there. It is a simple thing to do with the TEMPO() command as Frederf said using the TARGET Script Editor, or once you create a profile using the GUI, you can View the Script, and edit the script file to add the TEMPO command. But that script must then be compiled and run in the Script Editor I believe. I don't use the GUI so I am unsure of that.
  22. Ya, I would continue to look at possible hardware issues. You also should contact Thrustmaster support. Then again, if this is only happening with the TARGET Device Analyzer, my experience with that program is that it is very buggy. I stopped using it, but your question prompted me to try it again. It is actually working OK. The issues I had were it would not close without crashing, and it wasn't able to correctly identify the game controller devices. But that problem has gone away. Anyway, I don't really trust that program to be reliable.
  23. An Exception is a pretty serious error, either due to corrupted software, or a hardware issue. Since it is a fresh install of Windows, that hopefully rules out corrupted software. It might be a piece of software is missing or you have an older version (like required dependencies such as Microsoft supplied libraries). Though a fresh install of Windows should have everything up to date. The fact that it happens sometimes and not others, and because you mention in the past you have reinstalled the software and it fixed things, but it keeps coming back - this is all indicative of an intermittent hardware issue like a USB port issue or maybe something wrong with your Cougar. Have you tried connecting the Cougar to different USB ports? Like direct on the motherboard back panel vs. a hub vs. a USB port on your PC case (which probably connects to your motherboard). Again, maybe you have a loose or intermittently bad USB connector? Do you have any other Thrustmaster devices to try this with? Or does this happen if there are no USB game controllers attached? I think the analyzer only works with Thrustmaster devices, but non-Thrustmaster devices might be affecting it. What other USB game controllers are attached? I have seen the Thrustmaster Device Analyzer have some difficulties and I never figured out why, but I wondered if it had trouble with non-Thrustmaster devices connected. The difficulties were UI issues and not quite running correctly, but never saw it crash.
  24. It looks like someone did a custom mounting plate, unless Wheel Stand Pro sells this plate. I have the setup pictured (the Deluxe V2 setup), with the standard plate. It would be a simple conversion to remove the large rectangular plate and make a plate that goes from the Wheel Stand Pro to the Warthog stick. It is just a question of whether anyone is selling it, or if you have the skills and tools to make one. You might even be able to drill the Wheel Stand Pro's existing top mount with a hole pattern that matches the Warthog stick base. In the picture, it looks like the Warthog is mounted directly to the stand's top mount. Where did the pictures come from? Was there any explanation?
×
×
  • Create New...