0TreeLemur

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.

I updated FF to the most recent version (16.1, January 2024) and it seems that they have fixed the "bug" that got me started on this rant. With the iPad connected to the Stratus using the open-ADS standard, it now displays traffic. Guess I'll keep my FF subscription alive. I'm sure the frat boyeez* at Boeing will sleep well tonight (Whew! We kept one user!) Strangely- after the upgrade, it showed traffic, elevation, and tail # info. After a while it stopped showing that info, just the cyan triangles moving across the screen. <edit> That was a zoom issue. If you zoom out far it stops showing the details. All good so far.

So maybe not overworking the A/P either. Good to know. Here's the deal. It just displeases me when I'm doing a preflight and I start to move a control surface and I hear a "thunk" sound.

Good to know. Agree. Might make that good 'ol KFC-150 work harder than it should.

Agree. She handles fine. I'm more thinking about failure. Suppose they are the original 40+ year old parts, the slop is significant. At some point one of those could fail, which I imagine would cause me to have a Really Bad Day.

While hanging out at the airport Monday (Clear - 70F) giving our M20J a belly rub and applying some Tri-Flow, I noticed that the Heim bearings connecting to the ailerons are worn and have some slop. I'm talking about the connection from the push rod end to the aileron. Looking at the parts manual (p.2, sheet 27-10-00, 2003), it looks like there is a manufactured push rod from the bell crank to the aileron with two Heim bearing ends, (1 ea.) P/N M34-14MPB and (1 ea.) P/N M44-14MPB. How much slop is allowable? Is there a procedure to check it? For estimation purposes, if they need replacement, how many hours would it take an A&P to remove, replace the bearings, and reinstall one side? Looks like a pretty tough job. Thx. Fred

Blame Canada!

Great news! Glad the problem was not something more.

Yes. See: https://rudyaircraftinstruments.com/overhaul-prices

Here's an important question- how many years (typ.) does it take the EarthX battery to decline to 80% capacity? Our familiar Concorde seems to last 4 sometimes 5 years. If the EarthX has a considerably longer lifetime until it gets to the magical 80% minimum capacity the FAA specifies as "acceptable" at annual, then it might make more sense?

If I connect FF (client) to IFD (server) it prevents the IFD from connecting to the Stratus as a client for traffic info, because Stratus is only configured as a server. This setup will give FF position info only because I don't have a $$certified ADS-B in source wired into the IFD. Make sense? What I want was working from late August-Nov. of last year- I know how to do it. A FF update broke it. Others on the Avidyne Facebook group confirm.

Thanks Rick. I did read that. The Stratus 3 cannot be a client because its designed solely to be a server. That prevents the flow of traffic data to the IFD unless the IFD connects as a client to the Stratus server. I could solve this problem quickly by buying/installing a certified Avidyne ADS-B receiver. That's waaay down on my priority list right now. Plus they are really expensive compared to a Stratus. The steam is going out of my sails regarding moving from FF to something else. My subscription runs until Oct. Maybe FF will fix the bug that is affecting me. Several other people on the Avidyne facebook group report having the same problem. But it seems that the Stratus+Avidyne+FF crowd who display traffic on their Avidyne is not huge. -Fred

What does this mean? Let me translate the above plus what is written at foreflight.com/connect/spec: Oster blenders can by used for other purposes, not explicitly supported by Oster. Non-approved items put in this blender may get blended. Oster does not support blending of non-approved items in this blender, and may take this feature away at any time for any reason. Ok. It seems that this is what they've done.

Maybe an ignorant question. I searched through this thread and it doesn't seem to have been discussed. What log book entry is required if owner produced seat rollers are installed? Is that something that requires an A&P sign off?

Today I learned that the Stratus 3's so-called "open ADS-B" mode is really a Garmin Pilot format. That's why FF doesn't do it. That said, apparently the Stratus 3 always provides GDL90 output on a certain port using UDP packets. FF probably doesn't trust the GDL90 standard because some transmitters give ownship elevation in height above WGS84 geoid rather than mean sea level as required by aviation standards. FF extended that protocol to add a discriminator to detect this, but that extension is not universal. So- Anybody here use Appareo Insight EFB? Apparently, it can access the "always there" Open ADS-B format data from the stratus, which means you can simultaneously configure the Stratus 3 to transmit either one of either Garmin Pilot or FF formatted data as well. That solves my Avidyne connectivity problem. The www site for Appareo Insight honestly feels stale. Lots of two+ year old news items. A search of Youtube turns up mostly 3 year old videos. While it looks similar to FF, it lacks some functionality, while offering a few different features that FF doesn't have.

All I know is: My setup with IFD540 and FF connected as clients to the Stratus 3 using the GDL90 "Capstone" open ADS-B standard worked from Sept-Nov. of last year, but doesn't now. Nothing changed in my configuration. Except immediately upon startup, FF no longer shows traffic when connected to a Stratus 3 configured to use the open ADS-B standard. It worked continuously for long flights last fall. Conclusion: they "broke" FF. Some bugs are bugs. Some are features.