UGB-16 Settings

[Htmlkid]

Just curious to hear from anyone who is using a UGB engine monitor or other type of engine monitor what temps do you use for your high and low settings.

[Vance Harral]

We have a UBG-16 in our M20F (IO-360-A1A).  We have high temp CHT limits set on all four cylinders at 390.  We originally set them at 380, but found that was causing us to get an alarm during essentially every climbout in the summer.  That was in turn training us to ignore the alarm, which is not a good thing, so we upped the limit.  Turns out a 10 degree increase was all it took to almost entirely eliminate the nuisance alarms.  In general, I expect CHTs to be in the high 300s on climbouts, and in the low 300s in cruise with the cowl flaps closed.

We don't set low CHT limits.  First, they'd go off on every engine start, and again that just trains you to ignore the alarm.  Second, if a cylinder actually quit in flight, the resulting significant roughness would indicate what was happening way before any temperature alarm.

We don't have any limits at all set for EGT.  Absolute EGT values are generally uninteresting, particularly on a normally aspirated engine.  We also don't enable any alarms for EGT or CHT differentials, or rates (We are unconcerned about "shock cooling").

This thread reminds me that I should probably set an alarm for high oil temp limit.  The oil temp probe is a recent addition, and I haven't gotten around to re-programming the UBG since it was installed.  The factory gauge redline is 245, but I'm inclined to set the alarm at 225, which is the top of the green arc.

[WheelPantsOff]

On 8/4/2023 at 10:57 AM, Htmlkid said:

Just curious to hear from anyone who is using a UGB engine monitor or other type of engine monitor what temps do you use for your high and low settings.

Do you have the data logger for your UBG-16?  I am considering adding it to download data and upload to a vendor.  I know the UBG is discontinued but I can't justify the added expenses of their newer unit and for under $1k installed, I think the MUX-8A is a good interim compromise.  Thanks in advance.

[47U]

On 8/6/2023 at 1:12 PM, WheelPantsOff said:

I am considering adding it to download data and upload to a vendor.

The rate at which the MUX records data is not as fast as the CGR units.  I think the fastest it would record was at 6 seconds?  The slower record rate limits some of the analysis capability, per feedback from Savvy.

And, since the UBG-16 is not certified as primary, you’re using a piggyback CHT probe on whichever cylinder has the factory CHT probe installed.  The install instructions say to put some fire sleeve around the piggyback.  Without it, my #3 cylinder was a good 30 degrees cooler than the other three cylinders.  With the fire sleeve, it appears to be right inline with the others, but I really don’t know just how accurate it is.

I started out with just the EGT/CHT data on my UBG-16, and found that lacking without corresponding MP/RPM/FF… so I added modules for those.  It’s a nice crosscheck with the analog gauges, but still not as clean as a newer engine monitor with more data visible without toggling through the display.  

Lastly, the serial interface the MUX uses to download data is glitchy.  The download software is ancient, and I the analysis software isn’t compatible with W10.  I can import the data to excel and build graphs from there, but (I assume) it’s not nearly as clean as newer technology.

[Vance Harral]

47U is correct, the highest frequency sampling for the MUX-8A is every 6 seconds.   This is fine for monitoring long-term trends, but won't work for Savvy's FEMA analysis that attempts to identify early signs of exhaust valve failure from high-frequency "wiggles" in EGT data.  Speaking of Savvy, you can upload the *.CSV files you get from MUX-8A downloads directly to their online analyzer, and it handles that fine - no need to import into Excel and make your own graphs.

We don't have MP or RPM on our UBG-16, but we did add fuel flow, for the same reasons 47U mentions - analysis of EGT/CHT behavior is essentially meaningless without an indication of what power the engine is operating at.  In our case, we felt fuel flow was good enough, but obviously having MP and RPM as well provides a clearer picture.

Speaking of fuel flow, here's a cool story about EI customer support: our airplane already had a Shadin fuel totalizer, so we didn't purchase another fuel flow transducer along with the EI fuel flow module.  I reasoned that I could just adjust the fuel flow module to match the K-factor of the transducer for our existing Shadin, and wire it in parallel with the Shadin wiring.  That idea was sound, but it turns out the potentiometer on the fuel flow module doesn't have enough range to match the K factor of the transducer for the Shadin.  When I was working with EI customer support to understand this, they immediately understood what I was trying to do, and built a custom fuel flow module for me and exchanged it for the unit I had purchased, for free.  This sort of thing is basically unheard of in the modern era of electronics.  It's made me a lifelong fan, though I confess the bloom is slightly off the rose for me in recent years.

I haven't had the same frustrating experience as 47U regarding data download, we've been trouble free.  On the hardware side, there's a trick to this: the MUX-8A uses an RS-232 interface which is now ancient.  Downloading data to a modern computer requires an RS-232-to-USB adapter.  Many of the inexpensive ones are "junk hardware" that have poor signal integrity, and assume the computers on either side of the link are going to mitigate that via checksum/resend algorithms which the MUX-8A doesn't employ.  If you buy a higher quality adapter, e.g. https://www.amazon.com/KeySpan-High-Speed-Serial-Adapter/dp/B0000510Y4, that eliminates the glitching.  EI was pretty clear about this back in the day, but now that the MUX-8A is old, information about it isn't nearly as prominent.  On the software side, I don't understand the comment about the DRS-1 analysis software not being compatible with Windows 10.  I got a new Windows 10 laptop earlier this year, and I installed DRS-1 on it and downloaded data from our MUX-8A just a couple of months ago.  Might have something to do with the version of software, I suppose.  The latest version is available for download on EI's web site: https://iflyei.com/wp-content/uploads/EI-DRS-1-Software.zip

One other bit of trivia: the MUX-8A contains an internal, battery-powered clock, which is set at the factory with the current day/time.  That's how it timestamps data.  The life of this battery is on the order of 10 years.  When it fails, the timestamps in your data for every flight revert to some date in the long-past which the manufacturer of the internal clock IC set as the epoch, and this means you can't distinguish any flight from any other flight.  We sent ours back to the EI for this problem.  They "serviced" it for $300, which turns out in practice to mean they threw it away and sent us a brand new one for a 10% discount off retail price.

[WheelPantsOff]

That's great, guys.  Thank you.  I ditched my Windows laptop a few years ago.  Is their software compatible with a Mac Book?  I have USB-C's but I'm sure I can get adapters.

[Vance Harral]

There is not a mac port of the DRS-1 software.  Mac users typically run Windows software via Bootcamp or Parallels to solve this sort of problem.