0TreeLemur

Hmmm. When I bought this J it was only turning about 2630 rpm on takeoff. I complained to my A&P and the governor required adjustment. Now it makes 2690-2700 rpm.

I live close to Sea Level. On takeoff, full power with full rich EGT on my IO-360 is about 1250F with a fuel flow of about 19 gph. I climb full throttle, full rpm (2700) to cruising alt. Once I get to 5000 ft, I'll lean until the EGT rises to about 1250F. I'll lean every 1000 ft or so to keep it at 1250. I fly out west quite a bit. In fact, I learned to fly there. At density altitudes greater than 4000 ft I was taught to take off with the mixture pulled to an extent that kind of comes with experience. My instructor during my pp training had me pull it about an inch in a C152. Last summer I took off from a field with a D.A. over 9000 ft. I had the mixture pulled about 2 inches on takeoff, and used that 1250 EGT to adjust it once the engine got up to full power. It took forever to get off the ground and I was on a 6000 ft runway so I had time to watch it. I agree with @EricJ, your redline should be 2700, and that red arc should be a yellow arc. If your engine is not making 2700 on takeoff, you should have your governor adjusted so that it does. If you don't have one, a great first upgrade for an older Mooney is an engine monitor.

Could you see the curvature of the Earth from up there?? Seriously, how long did it take to get to 17.5? 30 mins?

Thanks. I e-mailed them.

Yep- I've been using it while troubleshooting some ADS-B in issues in the hangar. My J has the quick-connect ("Audio Authority" as the man in the video calls it) shown in the video installed. That's the connector on the right-side of the photo in the OP. My hypothesis is that the problem stems from the aluminum connector with high internal resistance.

Yes- original connectors. I have to believe that for what it cost, the designer of the Battery Minder built in a high quality current limiting capability with internal fault detection. Just the connector is hot. The wire is not getting hot. It seems that high resistance in the connector is the most likely explanation.

Both are getting hot. In the photo above, the charger is on the left, and the connector to the battery on the right. Looking at the degree of melting, I might be convinced that the battery-side is getting hotter?

This connector on my battery minder is getting hot. As the photo shows, hot enough to deform the plastic. Anyone else had this happen? Clean or replace with a different connector? Thx, Fred

I was testing when there was a fair bit of traffic at TCL. Lot's of nearby targets, so that setting doesn't influence what I was seeing, which was no traffic on the iPad at times.

Since buying this airplane in Dec., 22, I never used the big red ("Easy"?) disconnect button. I always used the A/P button on the computer, or tap the trim switch. In fact I only used it once just to see if it worked - and then these problems started! Once I get it that switch replaced, I'll never intentionally use it again unless nothing else works.

Wow. Thanks for the description. I'm kind of surprised it only took you three hours. The flap hinge cover on our J is pop riveted on. Removing that sounds like it would be tricky to not damage that plastic cover?

Is this wiring diagram correct for the KAP/KFC150? If so, I like it a lot better than the one in the install manual. Thanks, -Fred

I feel your pain. The KFC-150 in our J stopped passing its self tests intermittently in November. The electric trim works, so I am pretty sure it's not the trim switch. I've had a busy time at work and uncooperative weather preventing me from getting it worked on. I did have an A&P clean the contacts and reseat A/P computer with negative effect. Flying back from his shop I mashed on the A/P Disconnect switch, and it passed the self test and worked the rest of the flight home. Hasn't worked since though. From reading about this, I'm convinced that it is the A/P Disconnect switch. I just need to have a shop put it in and see if that solves the problem. I've learned this: The A/P disconnect switches are problematic. All the current going to the servos passes through that switch. The contacts are running near their rated limits. They often fail. When the resistance of the contacts in that switch goes up it causes the A/P computer to fail its self test. A guy in the UK has a great web site describing the problems. He has a KFC225 A/P, but it uses a lot of the same switches.

That happens to me from time to time depending on winds. I had my SensorCon CO detector actually start beeping once while on the ground with the engine running. The exhaust smell was pretty strong. I had the door cracked and storm window open because it was hot in the cabin. I heard the beeping through my noise canceling headphones. Its' pretty loud.

Thanks Eric. I know well the disappointment involved in taking the theoretically sensible path only to find that is a slippery mud pit. I tested the iPad/Stratus GDL90 combination again this Friday evening after pulling the plane out of the hangar and powering everything up. There were lots of planes flying around the airport so I got a good test in. Oddly enough, traffic display was more reliable on the IFD-540 than on FF! I've read that receivers re-broadcasting ADS-B data using the GDL-90 standard do so using UDP on port 4000. This makes me think that somehow my iPad is dropping more UDP packets than the IFD. Aside from FF trying to get me to switch to ForeFlight mode for the connection to the stratus, my iPad required several restarts of FF to get a reliable connection while hitting "cancel" at each restart to keep the stratus in Open ADS-B mode. Something fishy going on here it seems with either FF or the iPad itself. My problem seems to be solved. I just really want the traffic to appear of the IFD because it is in my scan, and I use the iPad exclusively to view maps/charts. That seems to be working for now. Fingers crossed.

I like this set of figures that show the effect of airfoil curvature, which is a proxy for streamline curvature near the wing surface, on the distribution of pressure for 0, 5, and 10- degree angle of attack. The arrows show the deviation of the pressure from static. Arrows pointing away from the surface denote pressure less than static, while arrows pointing towards the surface denote pressure greater than static. The length of the arrow denotes the magnitude of the deviation from static. Pressure always acts normal (perpendicular) to the surface. Notice that minimal pressure deviation is produced where the streamlines are straight. The curvature of the streamlines creates a pressure gradient by Newton's 2nd law written normal to the streamlines. At the highest angle of attack (10-degrees) where the stagnation streamline terminates well below the leading edge, there is radical streamline curvature and a lot of pressure deviation where that happens. It looks like this creates a lot of forward thrust. In reality it doesn't because the area that this large negative pressure deviation acts on is small. Incidentally, it does provide a tiny bit of thrust that is offset by the increased drag due to separation further down the airfoil. This simulation does not show that separation realistically for high angle of attack. At the trailing edge, there is a net upward force on an aileron if present, but as previously mentioned a small upward deflection would balance that force. The lift is the integrated effect around the airfoil.

Super weird. The stops should prevent motion excursions, making it velocity independent. Thixotropic lubricant behavior? Maybe you've got a thick wad of old grease somewhere that is dynamically sensitive. Of course, that's a wild-a$$ stoopid guess. The fact that you can "un-stick" it by the right combination of slow movements indicates that it's a mechanical hang-up of some sort. A scary one at that. Can you post a video to youtube? I'm really curious to see the input motion that revealed this to you, mostly so I can subject my test airframe to the same motion to make sure that it doesn't suffer from such weird behavior too. Good find, and good luck getting it diagnosed and fixed.

Sorry if I missed this, but once it binds, how do you get it un-stuck? If it was a wire or bolt catching, it seems that it would be impossible to "un bind" it.

Thanks. A couple of hours. Anyone else miss Clarence? I sure do.

Another follow-up: In my deep dive into this problem I learned something about why the GDL90 standard is not universally supported. Garmin developed this standard and it includes lots of information latitude, longitude, ground speed, heading, VSI, and pressure altitude, true altitude, gps altitude, etc., but there is no assurance that all outputs will be provided. Some ADS-B "in" boxes don't output the true (msl) altitude or the information needed to calculate it. Some manufactures of ADS-B "in" boxes chose to report altitude relative the the WGS84 ellipsoid, but not relative to msl. This explains why some manufacturers of displays or EFB's are unwilling to adopt it as an open standard. The problem arises if the app/device processing/displaying an incomplete GDL90 data stream doesn't know either the barometer setting or the pressure altitude, it cannot show the correct elevation difference between ownship and ADS-B targets. It can be off by as much as the difference between true and pressure altitude on any given day. The Garmin GDL90 standard is really complete. Too bad it isn't fully implemented by some manufacturers. If you are interested, here's an example of what is included in the standard if fully implemented, including AHRS outputs (source: https://github.com/cyoung/stratux/blob/master/notes/app-vendor-integration.md) { "GPSLastFixSinceMidnightUTC": 67337.6, "GPSLatitude": 39.108533, "GPSLongitude": -76.770862, "GPSFixQuality": 2, "GPSHeightAboveEllipsoid": 115.51, "GPSGeoidSep": -17.523, "GPSSatellites": 5, "GPSSatellitesTracked": 11, "GPSSatellitesSeen": 8, "GPSHorizontalAccuracy": 10.2, "GPSNACp": 9, "GPSAltitudeMSL": 170.10767, "GPSVerticalAccuracy": 8, "GPSVerticalSpeed": -0.6135171, "GPSLastFixLocalTime": "0001-01-01T00:06:44.24Z", "GPSTrueCourse": 0, "GPSTurnRate": 0, "GPSGroundSpeed": 0.77598433056951, "GPSLastGroundTrackTime": "0001-01-01T00:06:44.24Z", "GPSTime": "2017-09-26T18:42:17Z", "GPSLastGPSTimeStratuxTime": "0001-01-01T00:06:43.65Z", "GPSLastValidNMEAMessageTime": "0001-01-01T00:06:44.24Z", "GPSLastValidNMEAMessage": "$PUBX,04,184426.00,260917,240266.00,1968,18,-177618,-952.368,21*1A", "GPSPositionSampleRate": 0, "BaroTemperature": 37.02, "BaroPressureAltitude": 153.32, "BaroVerticalSpeed": 1.3123479, "BaroLastMeasurementTime": "0001-01-01T00:06:44.23Z", "AHRSPitch": -0.97934145732801, // Degrees. 3276.7 = Invalid. "AHRSRoll": -2.2013729217108, // Degrees. 3276.7 = Invalid. "AHRSGyroHeading": 187741.08073052, // Degrees. Process mod 360. 3276.7 = Invalid. "AHRSMagHeading": 3276.7, // Degrees. Process mod 360. 3276.7 = Invalid. "AHRSSlipSkid": 0.52267604604907, // Degrees. 3276.7 = Invalid. "AHRSTurnRate": 3276.7, // Degrees per second. 3276.7 = Invalid. "AHRSGLoad": 0.99847599584255, // Current G load, in G's. Reads 1 G at rest. "AHRSGLoadMin": 0.99815989027411, // Minimum recorded G load, in G's. "AHRSGLoadMax": 1.0043409597397, // Maximum recorded G load, in G's. "AHRSLastAttitudeTime": "0001-01-01T00:06:44.28Z", // Stratux clock ticks since last attitude update. Reference against /getStatus -> UptimeClock. "AHRSStatus": 7 // Status bitmask. See main/sensors.go -> updateAHRSStatus(). }

I did that once using the drag polars that you posted a while back. Here are the calcs. For the assumed conditions (low altitude, 165 mph), the angle of attack is less than 1 degree up to gross weight.

From sondes? I know the models ingest sonde data when they spin them up.

Good find!

Lift is predominantly a by-product of streamline curvature. That's why lift generation mostly happens near the leading edge where the airfoil is most curved. At a cruising angle of attack with the ailerons in trail the streamlines in their vicinity are pretty much straight. They will therefore produce no lift for that reason. I agree with @MikeOH that at the trailing edge of the wing or aileron the pressure is single-valued but there is a little pressure difference on average between the top and bottom, which will push the aileron up a little until its deflection creates and equal but opposite downward force. If appropriately balanced it shouldn't oscillate. I just convinced myself that if a Heim bearing on one aileron failed, there would likely not be dire consequences. Provided that the linkage to the other aileron remained intact a pilot would still have about 1/2 the normal roll authority. Thanks for the entertaining discussion!

@PeteMc I did kind of say that in jest. Not completely innocent because I was a member of AHP while an undergraduate at Embry-Riddle in PRC where we had female members too. I was think more of the party four-days-a-week kind of frat boyeez.