Oydoron

I know that the manual talks about getting the tail wheel sometimes getting stuck and needing to unlock it. I'm assuming here that you are already aware of the basic tailwheel locking behavior. I'm not sure if the above notes from the manual are actually modeled in some way, or if they are just taken from a translation of something original.

What about the hardest aircraft to land of all time? U-2 maybe?

Have you tried applying full brake, hitting the MW switch, apply full throttle, wait for it to power up, and release?

I think the reason it's so difficult for some people is similar to the reason why riding a bike in a bicycle simulator would be difficult. You just aren't getting the feedback. However, the FW-190 does have an instrument that tells you exactly what you need to know: You can see the action of the vertical needle in response to lateral acceleration. Watch the part of the video where he tests that function a few times and get the mechanism into your head. Then, when you are rolling down the runway, you can see it out the corner of your eye. You don't need to wait for the plane to start sliding left or right, you can see it starting to happen. Just stab the opposite rudder pedal. Once my brain got used to this automatic response, I've been able to take off under a much wider range of configurations, mistakes, etc.

It's not seeing any of the diff.lua files because the hex ID for each of my controllers is different. If I try to make changes, it saves the changes in slightly differently named diff.lua files:

This might be enlightening: http://www.airspacemag.com/history-of-flight/yellow-10-4310601/

I haven't tried an extension, but by modifying the curves I've been able to achieve whatever accuracy I want.

Have you tried http://www.amazonsupply.com/ ? What are the required dimensions?

Patents are very expensive to enforce. It is rarely worth it for a small inventor to get a patent unless they intend to sell the rights to the product to a large company.

Don't. TARGET is for software that can't handle input properly. DCS can handle everything just fine on it's own.

Given the horribly ugly method my which the brightness is implemented in the firmware, I don't find it surprising.

Has anyone checked to see if the firmware version has any effect on this issue?

I've gone though the firmware a bit, and I really feel that there is room for improvement. I'm just not sure yet if the way they have done certain things is due to design decisions or hardware limitations. Allen key? 2 minutes? As long as you don't tighten it with an allen key, it's just a thumbscrew, the entire process takes less than 30 seconds.

This is the image as displayed on the Rift screen. The lenses not only distort the image, but distort each color differently. When viewed through the lenses, everything looks normal.

Shouldn't be difficult, he'd just need to implement registers 0x0f, 0x10, 0x11, and 0x2e in the datasheet. And really with 0x0f and 0x2e, he can just ignore the writes and return fixed data. For 0x10 and 0x11, he just need to return pot values. The main complication is that you'd need to make a calibration program that rewrites the slew control calibration values in the config block.

The digital button inputs don't use I²C, just shift registers. There's a line to load the shift registers, and then a clock to get the data out one bit at a time. It's implement on the control chip via it's SPI interface. It also looks like it supports the as5011 as well, don't think that helps you though unless you happen to know of a specific product. Since there are 7 conductors in the cable, the pins in no particular order are most likely: SCL SDA Shift register output (SPI_MISO) Shift register reset (SPI_CS) Shift register clock (SPI_CLK) Power Ground

Ah, there is an interface board within the grip. I had noticed that the firmware communicated with the slew control via I²C and assumed that the slew control itself had an I²C interface. From your photos it appears that the I²C interface chip is on the interface board within the grip. ETA: Yes, I took my throttle apart, and the slew control is certainly I²C. It's an AMS AS5013, which is a hall sensor solution in a single package with an I²C interface. So I'm a little confused on how you expect all this to work. If you want to make a replacement slew control using the same sensor and interface, the chip is available from digikey in single quantities: http://www.digikey.com/product-detail/en/AS5013-IQFT-1000/AS5013-IQFT-1000CT-ND/4740976

My curiosity is peaked on these. Any chance someone could do a usb packet capture for me? Or maybe just the corrupted descriptors?

Don't use TARGET with DCS. No drivers or anything are required.

The slew sensor in the Thrustmaster is I2C based. If you replaced it with a different sensor, you'd certainly need to interface it completely separately from the existing throttle.

The throttle meets the USB 2.0 specification, but it isn't a high speed device. Its just a full speed (12mbps) device.

So anyway, I scoped it and it looks like they are bitbanging the PWM quite poorly. Bitbanging is using the CPU to write out the PWM signal bit by bit, due to time variations, the signal tends to jump around. The alternative is to use dedicated PWM hardware, which I'm guessing they don't have. Here's a good capture that demonstrates that they are very likely bitbanging the PWM signal: This little cutout happens too rarely to cause an issue, but it does indicate that there is likely a software loop handling PWM and it has some discontinuity at the end/beginning of the loop. Anyway, here's a demonstration of the actual problem: You can see that the width of the pulses varies quite a bit, and the measured duty cycle and frequency does too. I've seen it vary between 40% and 50% in the default power on condition. I would guess that it would be worse at lower brightness. It may be that a driver/firmware update may be able to improve the situation, but I'd need to take a look at what chip they are using and see what their PWM code looks like.

I took a look at this a little more closely, there is definitely a ~30Hz or so beat. I'm curious now. I'll scope it next week and see what's up.

Normally, 60Hz flicker in peripheral vision is easily detectable. Higher for many people, but not 200Hz. Still, 200Hz is really low for a LED PWM frequency. The problem is that when the duty cycle is low, you can easily see the individual flashes if your eyes are moving with respect to the LED as a dot dot dot pattern.