Teej

I learned yet again yesterday that no matter how much I love the force mod...especially for flying F-16s...I, personally, flat out fly better with a moving stick. I know it won't be that way for everyone, but it is for me. Not only is my formation work smoother...but it was a real eye-opener when I popped into the F4AF dogfight module for the first time in about 3 years yesterday. I'd have to say that from the late 80s to the late 90s, I think I was pretty good at dogfighting. I lost interest and got into bombing and later SEAD. While playing in some F4AF squads, I dipped my toe back in the dogfighting realm (now with the FCC Cougar) and I both didn't like it and I stunk at it. I'd say back then...even after "practicing" for a while...when I went up against the AI Ace Mig-29 with me in the F-16....I lost probably 28 out of 30 fights. Maybe even 29. Shouldn't be that way. The AI isn't that good. Now...I was working on a Jagstang-like profile for the 'hog. I was about ready for bed and figured I'd go up and play with the -29 for a bit. Went in and flew rings around him 'til I had 3 kills. Thought to myself "Did you put invulnerability on? Leave the AI in rookie?" Nope. Full ace. Flew flat and level 'til I got shot down to verify there wasn't something hosed up. Thought "Huh. that must've been a fluke." Nope. Went 3-0 on several more flights. I know due to lack of practice I'd still get my ass handed to me by the dogfighting crowd...but that was simply an epic difference for me.

I would be stunned beyond words if power fluctuations small enough that most things (the computer itself) didn't notice / fry would cause enough of a change on the USB line to pop a Warthog. If a PC's power supply and motherboard setup to feed the USB were as simple as a stepdown transformer and a rectifier, I could maybe buy that argument. With multiple step voltage conversion/regulation...I think it's bordering on impossible. I truly do want to know what the answer ends up being. I really don't think it has anything to do with: 1: Position of switches / axes on the throttle when plugging in / powering on (Aside from the combo they've programmed in as a 'reset' which is something you'd have to do very deliberately) 2: Mains voltage fluctuation (that said, I run my computer from a UPS...) 3: Brand of motherboard (unless Asus got a large shipment of bad vregs in)

Each MFD has 2 indicator LEDs - one on either side of the top row of MFD buttons. You can also switch off the backlighting as a whole.

Sure enough. I went googling and see systems like that in discussions on the -16 and others too. Learn something new every day. :D I knew/suspected planes like Air Force One had something like that...just didn't realize it was making its way down to fighters and tactical jets.

Hmmm. Forgive me as I've not read into A10's manual in detail so it's entirely possible that there's some system (real and simulated) that I don't know about. I certainly don't claim to know everything! In the absence of such system...why would you get a launch detection on an IR missile at all, no matter who it's fired at? I would only expect a launch warning when you've had a radar homing missile fired at you. It is my understanding that this sort of detection works off the radar wavelength and PRF to tell when a radar system has gone from track to guidance mode and is focused on you.

We're playing with a couple of ideas to see what we like best. This actually got done on the first beta with LED control, and there was an update to the software 2 days later that changed a few things. In short, obviously we (VTB) don't worry about a lot of combat related switchology...the Warthog profile essentially similar to the Cougar profile we've had up on the site for ages. The current implementation has: Left ENG OPER switch pulled back shuts off all LEDs on the throttle. In the NORM position it turns them on. When pushed forward, it indicates whether the flaps, pinky, speedbrake and boat switches are all centered - separate LED for each, and there's a spare but I have an idea on that as well. Not all of the switches are easy to tell if they're in the right position without moving them around, so we thought we might try a quick "push to test" system. The right ENG OPER switch pulled back shuts off the MFD LEDs. Pushed forward it's an "all or nothing" test - similar to the left switch, but you either get 5 greens or no greens. LawnDart and I were going back and forth on which way to code it...so since we had 2 similar switches, I coded both to play with. Heh. This is somewhat inspired by the "push to test" function for testing cockpit lights and such in real aircraft. For us it verifies the profile is running and makes sure the smoke (dogfight), brake, etc. are set properly so nobody has to swear about an improperly set switch once the sortie starts. :D If by "program them without messing up plug and play" you mean the ability to use them without TARGET in DCSA-10...then no. You need to use TARGET to control LEDs. However...for those who want to be able to shut off the LEDs without yanking cords out...you'll be able to run the TARGET GUI and just switch the LEDs on/off manually.

Everyone's different. I went from an X45 to a force-modded Cougar (FCC). Used it for everything...Falcon..Warbirds / Aces High...even played driving/motorcycle games with it. I thought I had surgeon-like precision with it. Joining up with the VTB rejected that hypothesis...especially when I tried leading the team around. I prefer the concept of force input, and my FCC Cougar isn't for sale...but it is sitting on my shelf because I'm much smoother with the Warthog.

All the major systems need programming to work their best. It's been that way for 10 years...whether you talk TM, CH or Saitek. It's kinda nice that they're making TARGET in 2 flavors....GUI and script. The GUI does everything that most people will ever want. The script opens up a lot more doors. In either version, the 'boat switch' isn't 2 directx buttons...there's BSF, BSM, BSB (boatswitch forward, middle, back) that you can program. You can even make things conditional on one or more switch positions (in the script). As an example, for our VTB profile, I've got a switch set up as a sort of preflight "systems test" - pushing it checks that several of the switches are where we want them preflight and lights LEDs on the throttle accordingly (beta build of the next TARGET release...we're striving to help make sure it doesn't break anything). I've also written a very nice Jagstang-inspired Falcon AF profile for it. This stick is most certainly not "tied to" DCS or the A10.

You mean like being able to control the LEDs on the Warthog & MFDs? :music_whistling:

Not to mention the USB controllers on the motherboard itself. As to the OP's quote from TM...as the OP said he is on an imac, not an Asus board. I recall reading at least 1 bricked unit was used with a Gigabyte mobo, too.

Work smarter, not harder. :D Use the autopilot to hold flat and level while you find the power setting that allows you to maintain speed. On the takeoff training mission, holding 180 at 7000' takes about 80% power / 55% fan rpm. At some point during the climbout, I moved the LASTE switch to ALT/HDG. As I was passing 6500 feet I started pushing forward on the stick to level out at 7000 and pulling a bit of power. Tap the ENGAGE button for the autopilot and make final tweaks to power. Easy peezy.

I never realized Aragorn was active service.

Yeah, ALARM. Too bad we never got TACIT RAINBOW operational.

As one who has some background in circuit design, firmware writing and USB development...I would bet heavily against this being accurate. I don't think it's likely anything Asus related, given that I've heard of bricked throttles on Gigabyte mb as well as an imac. My money says one of the chips used has a higher than expected glitch/fail rate. Whether that's due to cost saving efforts at TM or the Chinese OEM or poor QC at the chiphouse I can only speculate. The failure rate, from what we've seen, pushes *my opinion* towards it being a parts quality problem at the component level rather than a design problem or firmware problem. Though there could be some of each. We have seen at least 2 failure modes, after all - total bricking, and simply dropping the firmware. If I'm wrong I'm wrong...but this is the way I see it.

Throttle & Joystick both report 100ma max power.

Asus P5B Deluxe - Ran pre-production Warthog from ~ May through November, production unit in November EVGA X58 FTW3 - Production WH November to current (caveat - although the Joystick unit is usually plugged into the motherboard USB ports, my throttle is usually (~ 70% of the time) plugged into my Dell 2408WFP monitor's built in usb hub)

Devices are only allowed to pull a certain amount of power...up to 200ma if memory serves...without negotiating with the OS for a higher level of power. The USB controllers tell the OS how much power they can supply and so on. If a device draws more power than it has negotiated for, the OS will shut down the device. Thus I don't believe an unpowered device could cause a "surge" like that.

I tried many iterations. I can tell you one thing I didn't ever do much of was holding any of the "momentary" switches on when I plugged it in as I figured that was how they would trigger a reset if there were a way to do so (like the trigger on the Cougar). I tried with as many switches as possible in a "button on" state (forward for a 2 way, anything off center for a 3 way) and with all switches neutral. Max throttle, min throttle, split throttles at opposite ends, etc.

I wish I'd had the patience to stick with what I was working on 5-6 years ago. At the time, the major players out there were Epic, x-keys and Hagstrom. I was working on creating a new little modular pit system but ended up putting it aside before I got much of it working. Ah well. It was quite a learning experience. Paid off on a school project a year ago. Heh.

I flew Warthogs from May through November on an Asus P5B Deluxe...and it was on that motherboard that I did the stress test attempting to force my preproduction unit to fail after some of the earlier reports of failures came out. Not counting the stress testing, the WH was plugged into a monitor the majority of the time, with power being applied and removed several times a day (cycling the monitor). Also spent a few weeks plugged into a motherboard USB port. Yes, plugging into the monitor most of the time does weaken the argument against it being the motherboard...but as I said there were weeks of regular use plugged into the motherboard, AND a pretty hardcore few days of testing with all kinds of unplugging, plugging, rebooting, power on/off etc. trying to get it to fail. I was taking notes on everything I did so that if I suddenly had it brick on me I'd have an "activity log" I could submit to TM. No luck. I've never had the stick itself plugged into anything but the MB, but again...that's not terribly significant since the throttle is by far the more likely failure, when it's happened. Just a data point.

I'm not gonna say you're wrong - I have no idea how right/wrong you are...but when you consider the very small percentage of units that have been returned (at least as far as we know)...the odds would be on TM's side just sending another random unit off the proverbial shelf back after writing the proper SN back to it. Thus, the "no second failure" doesn't really mean much.

That's like saying you're not gonna plug in your new mouse until you update the keyboard driver.

Unless they (microsoft) have really changed something that I don't know about (which is possible)...that number is telling you what the hardware mfr has specified as the max power usage for the device and/or max agreed upon between the device and windows...not the actual usage.

My default situation is, as it has been since I started testing the WH in May, with the WH throttle plugged into the USB hub that's part of my monitor (Dell 2408 WFP), and the stick plugged either into a powered hub or the motherboard. The monitor gets turned on and off several times per day. That said, any combination you can think of in regards to plugging and power, I'm sure I've done it, plenty of times...either with my current EVGA motherboard or my old Asus core 2 duo rig. I spent a fair bit of time trying to cause mine to fail, taking notes along the way so if I got it to fail I could tell TM precisely what I had done and in what order. I've never been able to bring about anything like this throttle failure.

10/18 is what I show after having done their firmware update. It was 9/17 before.