0TreeLemur

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.

Let me know if this still works for you. FF tech support told me yesterday that FF has always required receiving ADS-B data in FF mode, and has never supported the GDL90 Capstone ADS-B format. I call B.S. because my setup with IFD540 and FF connected as clients to the Stratus worked from Sept-Nov. of last year, but doesn't now.

Thanks. I read that Sunday while doing research. I had it all working until FF boinked up their shizzle.

Downloaded and installed. Testing with Stratus in open ADS-B mode.

The Avidyne 10.3.1.2 software upgrade specifically allowed an IFD to get ADS-B traffic info from a non-certified Stratus 3 or Stratux. It was a big deal. Doing so requires use of Capstone (GDL90) open ADS-B standard data format, which the Stratus 3 can send over wifi. This makes the Avidyne a client to the Stratus, just like the iPad. The iPad used to show traffic as a client connected to the Stratus 3 using the GDL90 standard. Still does at start up. But as soon as you hit "Cancel" on "Change to ForeFlight" on the iPad it stops. I've done a lot of work since last summer getting this to work. Something has changed in ForeFlight. The Avidyne has nothing to do with the problem I'm seeing.

When a software company takes away features that I rely on, I don't like it. When asked about why something doesn't work that used to work, and they reply "it never did", that pisses me off. Short version: In August I upgraded Avidyne IFD540 to s.w. version 10.3.1.2 so I could display traffic from stratus using Open ADS-B comms. As long as I hit "Cancel" on ForeFlight when it wanted to switch the Stratus to ForeFlight mode, it displayed traffic on the iPad too. Recently that stopped working on ForeFlight. When I asked Boeing about it, they replied that it never worked, which is Bull$hit. They took that feature away. I've been using ForeFlight since 2017. I like it. It did what I needed, until now. Which EFB should I switch to? I have an iPad, so I'm not eager to switch to a different platform. I'd also like to use something that runs on my iPhone. It must use the open ADS-B data standard. Thoughtful replies sought. "Stick with Foreflight" is not an acceptable reply. I'm steamed.

You can see the fitment of the aileron push rod from the first inspection panel outboard from the fuselage. You can also inspect the area where it passes under the fuselage and beneath the floor.

Hi Rob, it looks like not a lot of support here for the UBG-16 display. Nothing comparable on eBay. There are some US-8A's that have been listed for a long time. You might consider making an offer on one of those if you see one that looks like will work. Then again, I suppose your UBG-16 without bar graphs is more/less the same thing. -Fred

Another pinch point is in the wing root outboard of the fuselage where the push rod travels through an area that can be congested with wires. The left wing also has the pitot connection. When my A&P installed the JPI OAT probe in the first inspection panel outboard from the fuselage in our C, we struggled with making sure that there was no interference with the aileron push rod. If something came loose in that area it might impede push rod motion. They don't just translate, they also move up/down. Good luck! Let us know what you learn.

I dunno, my first sentence was meant to have a question mark. I've crushed a lot of beer cans, and boy are they hard to uncrush. Some PDR people are absolute magicians. Maybe you can find someone who can do it. Aluminum stress-strain curves have a linear region at lower loading, then a nonlinear region before reaching ultimate strength. Take the load off at this point, and it doesn't follow the exact same path back down the stress-strain curve- hysteresis. So, load history can affect its behavior. Kind of like what @Shadrach means when he used the term "memory". I would speculate that it depends on how close it got to ultimate strength when deformed. If not very close, PDR might just do wonders. If close, probably not. Post before/after pics when done!

Isn't it true that PDR doesn't work on aluminum because if the metal deflects enough to permanently deform it strain hardens. That changes the material properties. They'll never get it back to where it was before, its a different material. Maybe they can make it look a little better, but restoration like on a steel auto body isn't possible.

Back on topic, on takeoff Saturday I tapped the brakes before raising the gear. I noticed a challenge. Just before I advance power to take off, always I move my feet so that they are pressing only on the bottom of the rudder pedals. That keeps me from inadvertently applying any brake while on the roll. To apply brake, I had to move my feet back up to the middle of the rudder pedals. This movement required me to release the significant amount of right rudder needed to keep the ball centered. That caused my climb to wobble in a very un-aviation like way. How do other brake tappers deal with this? Sliding the right foot up the rudder pedal while pressing hard on climb out just doesn't seem doable.