Free AI Engine Analyzer (Beta) G3X, GRT, Dynon, Avidyne

[jquayle]

I've been quietly running an AI-powered engine analyzer for the past few weeks and the results have been interesting enough that I'm opening it up to anyone who wants to try it.

Engine Analyzer — Offline

Specify Engine/EFIS/Prop and then drop in log files like you would for Savvy and it analyzes your engine management habits across your whole flight history. You can try a single flight, but the more flights you include the better, since it's looking for patterns and trends.

Right now it's focused on:

• Leaning technique — taxi, climb, and cruise
• CHT management by cylinder
• Shock cooling patterns
• Oil pressure and temp
• EGT balance

It knows the difference between a carbureted O-360 and an injected IO-550, understands ROP vs LOP, and uses Mike Busch/APS methodology as its reference framework.

This is a work in progress. I'm actively finding edge cases and tuning it based on real submissions. There's a follow-up question box after the analysis. PLEASE give it a try. If it got something wrong or something doesn't make sense, say so. That feedback directly improves how it works for everyone. You can actively interact with the AI asking questions, making corrections, etc. This is one of the most unique features.

I'd love to know: did it catch something real? Did it get something wrong? What's missing?

Jeff

Transparency Notice: I am keeping a log of the interactions so that I can find instances where it made mistakes and try to correct and improve the AI.

 

[flysrv10]

I was not able to drop file or insert a file on Safari Browser. No upload.

 

[Raz]

My JPI EDM830 engine files are .JPI type. Is there a way to upload or convert those?

 

[jquayle]

I was not able to drop file or insert a file on Safari Browser. No upload.

Based on user feedback I made a change last night that allows the AI to go back and re-run analysis based on the user feedback. Broke the file import when I made those changes.

Fixed now


JQ

 

[jquayle]

My JPI EDM830 engine files are .JPI type. Is there a way to upload or convert those?

My understanding is that JPIs native format is in a proprietary format that they have refused to share (with the exception of Savvy). Their official recommendation is to run it through their own EZ-Trends software to convert to a .csv file.

I do have a JPI in a Bonanza I fly so there's a lot of personal benefit for me to get the info decoded, but I'm looking into using the RS-232 port and reading the info directly in real time rather than having to pull from the USB and work with their file format.

I'll post an update on this when I have more information.


JQ

 

[jquayle]

My understanding is that JPIs native format is in a proprietary format that they have refused to share (with the exception of Savvy). Their official recommendation is to run it through their own EZ-Trends software to convert to a .csv file.

I do have a JPI in a Bonanza I fly so there's a lot of personal benefit for me to get the info decoded, but I'm looking into using the RS-232 port and reading the info directly in real time rather than having to pull from the USB and work with their file format.

I'll post an update on this when I have more information.


JQ

Right after I posted this it occurred to me to see if anyone had reverse engineering ez-trends already. I found a git repository where someone actually has and apparently was able to was able to talk to a couple of JPI's senior engineers to confirm the format.

Short version is that all the hard work is already done. I just need to wire in what he built into the analyzer. That should be fairly trivial. More soon.


JQ

 

[bkervaski]

Link doesn't work, fyi.

I've been quietly running an AI-powered engine analyzer for the past few weeks and the results have been interesting enough that I'm opening it up to anyone who wants to try it.

Engine Analyzer — Offline

Specify Engine/EFIS/Prop and then drop in log files like you would for Savvy and it analyzes your engine management habits across your whole flight history. You can try a single flight, but the more flights you include the better, since it's looking for patterns and trends.

Right now it's focused on:

• Leaning technique — taxi, climb, and cruise
• CHT management by cylinder
• Shock cooling patterns
• Oil pressure and temp
• EGT balance

It knows the difference between a carbureted O-360 and an injected IO-550, understands ROP vs LOP, and uses Mike Busch/APS methodology as its reference framework.

This is a work in progress. I'm actively finding edge cases and tuning it based on real submissions. There's a follow-up question box after the analysis. PLEASE give it a try. If it got something wrong or something doesn't make sense, say so. That feedback directly improves how it works for everyone. You can actively interact with the AI asking questions, making corrections, etc. This is one of the most unique features.

I'd love to know: did it catch something real? Did it get something wrong? What's missing?

Jeff

Transparency Notice: I am keeping a log of the interactions so that I can find instances where it made mistakes and try to correct and improve the AI.

Link doesn't work, fyi.

 

[jquayle]

Thought it might be worth showing what you can expect using this and an example of the power of the followup questions.

Here's a analysis I just did.


btw - I've increased the capabilities of the Analyzer quite a bit in the last 2 days and the analysis is now taking quite a bit longer than it used to. I'm going to move this to more powerful hardware, but I wont have time for that until early next week. Please be patient with it. It took about 4 minutes for the initial analysis when I ran this.



JQ

 

[jquayle]

Link doesn't work, fyi.


Link doesn't work, fyi.

I just received this via email. Cloudflare might have blocked access if you weren't able to access the website at all.

Cloudflare detected 717 security threats for blackboxpi.com

 

[rmd]

I submitted a flight that was comprised of six, GRT DEMO*.LOG files and your code was unsuccessful.

I then submitted the CSV file from the same flight and it mostly worked, but didn't seem to capture the correct manifold pressure - it returned a note indicated the minimum was 1.0, but I don't find that value on Aux 5 where the MAP is wired.

I tried a third attempt with the LOG files zipped, but that, too, failed to produce a result.

Regards,
Rob
N706DR

 

[jquayle]

I submitted a flight that was comprised of six, GRT DEMO*.LOG files and your code was unsuccessful.

I then submitted the CSV file from the same flight and it mostly worked, but didn't seem to capture the correct manifold pressure - it returned a note indicated the minimum was 1.0, but I don't find that value on Aux 5 where the MAP is wired.

I tried a third attempt with the LOG files zipped, but that, too, failed to produce a result.

Regards,
Rob
N706DR

Did you tell it in the followup that MAP was on AUX 5?

I will take a look. Thank you for the feedback.


JQ

 

[rmd]

Did you tell it in the followup that MAP was on AUX 5?

I will take a look. Thank you for the feedback.


JQ

Yep, and I hate to admit that I already can't recall the result. My wife said lunch was ready and I was like a dog who saw a squirrel - immediately forgot what I was doing!

Rob

 

[jquayle]

Quick update:
Website is currently down. Having some cloud flare issues. Turning this public caused some problems due to heavy traffic (uploading large amounts of files) and cloud flare keeps shutting down access.

I'll work on this and have it back up soon.


thank you,



JQ

 

[jacoby]

Website is currently down. Having some cloud flare issues. Turning this public caused some problems due to heavy traffic (uploading large amounts of files) and cloud flare keeps shutting down access.

Might be worth protecting the upload behind cloudflare turnstile or google recaptcha or adding a register/login gate (also protected by turnstile or recaptcha). Anything that accepts data without a user login is attacked by bots almost instantly.

 

[jquayle]

Yes, I should have put more thought into posting in publicly. I'm working on that now.

Thank you.

 

[jclark]

Yes, I should have put more thought into posting in publicly. I'm working on that now.

Thank you.

Also, if you haven't checked, you may want to make sure that the "Analyzing" section has not been stuck in a loop, burning dollar$$$$ way beyond your expectations. I have come back to a submission a couple of times and noticed that it was "stuck" in what looked like the same place (about 80-90% done).

 

[jquayle]

Also, if you haven't checked, you may want to make sure that the "Analyzing" section has not been stuck in a loop, burning dollar$$$$ way beyond your expectations. I have come back to a submission a couple of times and noticed that it was "stuck" in what looked like the same place (about 80-90% done).

That's a very real concern and I did address that already a few ways. I have a fixed token budget and I've only purchased enough API tokens that I'm willing to spend for this (with no auto-refill)

The 'stuck' issue is because the model is currently running on very underpowered hardware. I'm moving the project to a box with enough power to handle it.

I appreciate you looking out for me on that issue though.


JQ

 

[Hangar 1271]

I thought I would give this a try this morning. I uploaded my Dynon user and black box data in 2 different uploads and it output a CSV file both times but never offered to analyze anything. Am I missing something or is the site still down?

 

[Hangar 1271]

I must be dreaming (or hallucinating). I received a notice of a new response to this thread. I went to the thread and it said the analyzer was back up. I tried it and it hung up about 80% of the way through. I thought I would come back to the thread to see if there was additional info and the response is gone as is the alert from VAF. Hmm.

 

[DanH]

Jeff, I took a look at the file from post #8.

As currently presented, it's not an engine analyzer. At best it's data consolidation with AI frosting. Examples...

Your lean-for-climb habit gets an EXCELLENT grade (100% across all flights), but I noticed you're not leaning in cruise on any of the three flights.

The AI is reporting pilot performance, not engine performance.

With your carbureted O-360, you should be leaning rich-of-peak in cruise — target staying well clear of the 50-150°F ROP "red box" where detonation risk is highest.

The AI is regurgitating an opinion, arguably true in a very general sense, but not necessarily accurate, and certainly not specific to the subject engine. An analyzer would detect and indicate actual evidence of detonation in this engine, perhaps a sudden rapid rise in CHT with decreasing EGT.

And where did this AI get the notion that a carbed engine can't run LOP? Reality is some can and some can't, with the primary variable being the quality of the sump casting. Again, an AI analyzer would be able to state a GAMI spread for this engine if the pilot did a simple mixture sweep, a tool some might like better than looking at EGT columns on .csv file, or a Savvy plot.

 

[jquayle]

Analyzer is back online. I've added a lot more complexity so if you submit several flights (max 30) you may want to wait for the email you'll receive when it's done rather than wait for it to finish.

Depends on flight length, not just number of files. A single 4MB G3X datalog has about 40,000 lines with dozens of inputs per line it's tracking.


Jeff

 

[jquayle]

Jeff, I took a look at the file from post #8.

As currently presented, it's not an engine analyzer. At best it's data consolidation with AI frosting. Examples...

Your lean-for-climb habit gets an EXCELLENT grade (100% across all flights), but I noticed you're not leaning in cruise on any of the three flights.

The AI is reporting pilot performance, not engine performance.

With your carbureted O-360, you should be leaning rich-of-peak in cruise — target staying well clear of the 50-150°F ROP "red box" where detonation risk is highest.

The AI is regurgitating an opinion, arguably true in a very general sense, but not necessarily accurate, and certainly not specific to the subject engine. An analyzer would detect and indicate actual evidence of detonation in this engine, perhaps a sudden rapid rise in CHT with decreasing EGT.

And where did this AI get the notion that a carbed engine can't run LOP? Reality is some can and some can't, with the primary variable being the quality of the sump casting. Again, an AI analyzer would be able to state a GAMI spread for this engine if the pilot did a simple mixture sweep, a tool some might like better than looking at EGT columns on .csv file, or a Savvy plot.

Thanks for the detailed feedback

You're right that what I posted is closer to pilot technique coaching than true engine analysis. That's partly intentional (helping pilots develop better habits) but may be thinking about this wrong. Coaching and engine analysis are two different products and trying to put them together might not be the right approach. Fair point, well taken.

My goal was to provide both in the debrief, but I'll look into splitting them. There is a lot of engine specific information that I've been able to pull from flight from myself and friends. The AI corrected detected that my MAP gauge is faulty (showing impossible values like 32" MAP at altitude) and that my FF sensor is prone to wild fluctuations (It wasn't installed by the builder downstream of the engine driven pump and reading jump wildly when I turn on the electric fuel pump) It also detected a failing fuel pump in another set of flights (which was replaced and fuel pressure reading now show as steady an appropriate.

On the carb LOP point: That was the AI overgeneralizing. Carb vs FI isn't the defining requirement for running LOP, a tight Gami spread is. The system shouldn't be asserting a blanket rule there. I'll correct it.

On detonation detection: That's something on the roadmap to be able to detect in real time in flight.


Jeff

 

[jquayle]

I must be dreaming (or hallucinating). I received a notice of a new response to this thread. I went to the thread and it said the analyzer was back up. I tried it and it hung up about 80% of the way through. I thought I would come back to the thread to see if there was additional info and the response is gone as is the alert from VAF. Hmm.

Not hallucinating. I had posted it was up this morning, but found not all the bugs were out yet and removed the post.

JQ

 

[DanH]

Coaching and engine analysis are two different products and trying to put them together might not be the right approach. My goal was to provide both in the debrief, but I'll look into splitting them.

Forget coaching. No one needs bad advice.

There is a lot of engine specific information that I've been able to pull from flight from myself and friends. The AI corrected detected that my MAP gauge is faulty (showing impossible values like 32" MAP at altitude) and that my FF sensor is prone to wild fluctuations (It wasn't installed by the builder downstream of the engine driven pump and reading jump wildly when I turn on the electric fuel pump) It also detected a failing fuel pump in another set of flights (which was replaced and fuel pressure reading now show as steady an appropriate.

Those examples demonstrate the AI is capable of detecting items post-flight which a competent human would have noted in real time. They are just instrument indications.

 

[jquayle]

Forget coaching. No one needs bad advice.

Respectfully, I disagree. I've read a lot of your posts and and I have a huge amount of respect for you and your opinion, but I think there are a lot of pilots that might be skipping or uninformed on the leaning techniques I'm giving feedback on. If you think that information is inaccurate please let me know how so. It's completely based on the APS and Mike Busch's teachings.

You also said that I'm not pointing out anything that a competent human would have noticed in real time. Again, I'm not sure I agree with you. I can't stare and every gauge 100% of the time when flying. Some of the issues detected were intermittent and only showed up occasionally. Also, what exactly happened and what the pilot remembers are often not the same. Yes, you might be able to get this same information if you looked over the engine data post flight but how many of us do that for every flight? How many people are going to look over dozens or hundreds of flights trying to find a small detail that might have overlooked? Personally, I have only ever really looked at flights when I really suspected there was a problem.

I've detected issues in every one of my friends planes that I've run large numbers of flights through (either with their flying habits or engine) that they themselves weren't aware of they have been confirmed post analysis, myself included.

I'm very open to any suggestions for improvement. I'm selling anything nor have I made any promises. I made this available because the people I had showed it to thought there was value in it.


Jeff

 

[Hangar 1271]

Jeff,

I ran the same flight through using the user log and the black box log from a Dynon/IO-360/CS prop. Interestingly, I received 2 very different AI debriefs. Is there a reason for the differences and should we be accepting/using one over the other?

 

[bkervaski]

There may be value in what Jeff is trying as an experiment ...

... but there should be considerable push back on using AI as an realtime decision making aviation tool where pilots that don't understand how AI works, in the sense that AI will definitely lie to you, the "bias in, bias out" problem, and the non-negotiable truth that the nature of how LLMs work will NOT allow for 100% accuracy.

The unknowing/uninitiated may take AI tooling information as fact when it can be convincing utter fiction.

 

[jacoby]

I'm very open to any suggestions for improvement. I'm selling anything nor have I made any promises. I made this available because the people I had showed it to thought there was value in it.

IMHO, implement the analyzer as Dan recommends. LLMs do not reason. You need a deterministic tool to build upon. After that is implemented the LLM can use the tool to provide a debrief and provide recommendation. Until then you're going to have non-deterministic results up to and including outright hallucinations as @bkervaski noted.

 

[jquayle]

Jeff,

I ran the same flight through using the user log and the black box log from a Dynon/IO-360/CS prop. Interestingly, I received 2 very different AI debriefs. Is there a reason for the differences and should we be accepting/using one over the other?

David,

You actually stumbled onto something interesting about how Dynon SkyView works and I had no knowledge of this myself until I investigated.

Here's what I found. You may want to verify this information is correct.

Your SkyView records two separate log files to the SD card during every flight:

"The User Data Log contains plain-text tabular data that records the entire state of your SkyView
system at a recording rate of your choosing (see below). This includes over 100 items, and
includes all ADAHRS (flight instrument) data, Engine parameters, GPS data, Autopilot status, SV-
XPNDR-261/262 status, time, and more."

"BLACK_BOX_LOG_DATA.csv — The Recent Flight Data Log records the most recent 15 minutes of flight at a data recording rate of 16 times per second, in the same manner as described above. Its recording rate cannot be
changed."

https://data.ntsb.gov/Docket/Document/docBLOB?FileExtension=.PDF&FileName=Miscellaneous+Information+-+Dynon+Installation+Guide+Excerpts-Master.PDF&ID=40473704&utm_source=chatgpt.com

Pages 26-1 - 26-2

Thanks for pointing this out. You're likely not the only Dynon owner that isn't aware of the difference between the 2 files.



Jeff

 

[jquayle]

For the non-nerds following the conversation, let's train an LLM (Large Language Model, aka "AI"):

Training data sample (scraped from the internet or pulled from existing databases):
1. The sky is red
2. The sky is blue
3. The sky is blue

Now let's ask it questions ...

Query: What color is the sky?
Response: blue
Confidence: 75% (can never be 100%)

Query: Is the sky red?
Response: no
Confidence: 75% (can never be 100%)

Query: Can the sky be red?
Response: yes
Confidence: 25% (hmm... interesting)

Query: The sky looks red today, is it?
Response: yes
Confidence: 25% (input bias)

Just imaging this simple example and add billions of data points, this is basically/conceptually how LLMs work, end-users generally don't get to see the confidence scores. We know the sky can never be red, it lied to us, unintentially without emotion or sense of consequences.

You're correct and how you train the AI makes a huge difference in the results. Early versions of this analyzer would say "I see your leaning for taxi and 63% of your flights" which makes is sound like your not leaving on the other 37%, but in fact after digging into it the other 37% was a combination of 'undetermined' and 'confirmed not leaning'. These are the tweaks I'm trying to make. Guardrails against AI hallucinations, realizing when the data is outside the limits of possibility, etc. It reported that a pilots CHT's were in the 700° range. It didn't make that up. That's what was in the data log, but it was obviously a bad sensor reading and the AI took the data as absolute truth. Once I started to define things that were impossible, it now is getting pretty good at finding potential sensor issues.

In my overall experience with AI I have certainly learned that AI can be very wrong and present that information with absolute confidence.

Also, sometime the AI can be right when you think the obvious answer to the question is that it must be Wrong.


Jeff

 

[wirejock]

David,

You actually stumbled onto something interesting about how Dynon SkyView works and I had no knowledge of this myself until I investigated.

Here's what I found. You may want to verify this information is correct.

Your SkyView records two separate log files to the SD card during every flight:

"The User Data Log contains plain-text tabular data that records the entire state of your SkyView
system at a recording rate of your choosing (see below). This includes over 100 items, and
includes all ADAHRS (flight instrument) data, Engine parameters, GPS data, Autopilot status, SV-
XPNDR-261/262 status, time, and more."

"BLACK_BOX_LOG_DATA.csv — The Recent Flight Data Log records the most recent 15 minutes of flight at a data recording rate of 16 times per second, in the same manner as described above. Its recording rate cannot be
changed."

https://data.ntsb.gov/Docket/Document/docBLOB?FileExtension=.PDF&FileName=Miscellaneous+Information+-+Dynon+Installation+Guide+Excerpts-Master.PDF&ID=40473704&utm_source=chatgpt.com

Pages 26-1 - 26-2

Thanks for pointing this out. You're likely not the only Dynon owner that isn't aware of the difference between the 2 files.



Jeff

Actually there's three log files for each display. User Alert, Black Box and User Data. Note the files are cumulative. Dynon just keeps adding till it reaches max then starts a new file. For that reason, I have a checklist item to clear log files before and after each flight. That way the log I download is unique to the flight.

 

[bkervaski]

You're correct and how you train the AI makes a huge difference in the results. Early versions of this analyzer would say "I see your leaning for taxi and 63% of your flights" which makes is sound like your not leaving on the other 37%, but in fact after digging into it the other 37% was a combination of 'undetermined' and 'confirmed not leaning'. These are the tweaks I'm trying to make. Guardrails against AI hallucinations, realizing when the data is outside the limits of possibility, etc. It reported that a pilots CHT's were in the 700° range. It didn't make that up. That's what was in the data log, but it was obviously a bad sensor reading and the AI took the data as absolute truth. Once I started to define things that were impossible, it now is getting pretty good at finding potential sensor issues.

In my overall experience with AI I have certainly learned that AI can be very wrong and present that information with absolute confidence.

Also, sometime the AI can be right when you think the obvious answer to the question is that it must be Wrong.


Jeff

I wasn't really critizing your project specifically, there's just a lot of folks that don't understand how this stuff works. It's amazing and can be incredibly useful, but its ultimately flawed. I wouldn't put the genie back in the bottle, it's going to be better having it than not having it ... until it isn't ... the paperclip problem.

 

[jquayle]

I wasn't really critizing your project specifically, there's just a lot of folks that don't understand how this stuff works. It's amazing and can be incredibly useful, but its ultimately flawed at the core. I wouldn't put the genie back in the bottle, it's going to be better having it than not having it ... until it isn't ... the paperclip problem.

I didn't take it as criticism, and your points are all correct.

Thank you,


Jeff

 

[Hangar 1271]

David,

You actually stumbled onto something interesting about how Dynon SkyView works and I had no knowledge of this myself until I investigated.

Here's what I found. You may want to verify this information is correct.

Your SkyView records two separate log files to the SD card during every flight:

"The User Data Log contains plain-text tabular data that records the entire state of your SkyView
system at a recording rate of your choosing (see below). This includes over 100 items, and
includes all ADAHRS (flight instrument) data, Engine parameters, GPS data, Autopilot status, SV-
XPNDR-261/262 status, time, and more."

"BLACK_BOX_LOG_DATA.csv — The Recent Flight Data Log records the most recent 15 minutes of flight at a data recording rate of 16 times per second, in the same manner as described above. Its recording rate cannot be
changed."

https://data.ntsb.gov/Docket/Document/docBLOB?FileExtension=.PDF&FileName=Miscellaneous+Information+-+Dynon+Installation+Guide+Excerpts-Master.PDF&ID=40473704&utm_source=chatgpt.com

Pages 26-1 - 26-2

Thanks for pointing this out. You're likely not the only Dynon owner that isn't aware of the difference between the 2 files.



Jeff

The lesson is to use the user log as it has numerous flights, unless you clear it or it is a very long flight, and the black box only has the last 15 min. Interestingly, the user log evaluation said it only looked at 1 flight but I know from uploading to FlySto that there are at least 3 flights of data. Curious.

 

[DanH]

If you think that information is inaccurate please let me know how so. It's completely based on the APS and Mike Busch's teachings.

Ok, same example, again:

With your carbureted O-360, you should be leaning rich-of-peak in cruise — target staying well clear of the 50-150°F ROP "red box" where detonation risk is highest.

Show us ANY available evidence from APS or Busch showing detonation at cruise power with a carbureted Lycoming.

 

[jquayle]

Ok, same example, again:

With your carbureted O-360, you should be leaning rich-of-peak in cruise — target staying well clear of the 50-150°F ROP "red box" where detonation risk is highest.

Show us ANY available evidence from APS or Busch showing detonation at cruise power with a carbureted Lycoming.

Dan,

You're correct. The "red box" (50–150°F ROP detonation zone) is an APS/GAMI concept derived from testing on fuel-injected engines at high power. It doesn't cleanly apply to carbureted engines because:

1. Carbureted engines have uneven mixture distribution between cylinders — one cylinder's "150°F ROP" might be another's "peak" or even LOP
2. The detonation risk at typical carbureted cruise power (65–75%) on a Lycoming is well-managed by the conservative APS ROP targets, but the specific "red box" framing was developed for injected engines
3. Mike Busch himself notes carbureted engines are harder to lean precisely and you lean by fuel flow/feel rather than chasing a precise EGT target

I've adjusted the AI so that carbureted engines get different, more conservative/accurate language.

That mistake wasn't a fault of the AI. It was me not knowing that I needed to make a distinction between carbureted and FI systems. The Analyzer and I are both getting better as I learn more. That's part of the journey for me. I'm learning a lot in trying to make this better and better. I hope you didn't feel that I was presenting it as finished work. It's examples like this that allow me to improve it.

Thank you,



Jeff

 

[DanH]

You're correct. The "red box" (50–150°F ROP detonation zone) is an APS/GAMI concept derived from testing on fuel-injected engines at high power.
It doesn't cleanly apply to carbureted engines because:

It doesn't apply to any stock Lycoming intended for an RV, injected or carbed. It's just wrong.

This is Lycoming dyno data, part of a report which escaped to the web years ago. A detonation test is run at >100F IAT, OT at max and the test cylinder CHT at max, here almost 500F. The subject is an injected IO-360 angle valve. The power setting is at the far stupid end of the scale, 28.6 MP and 2400 RPM.

Even under these highly adverse conditions, note the max detonation frequency is only about 12%, or roughly one combustion event in eight. Now look at the "50 to 150 ROP red box danger zone". It's mostly free of detonation; the worst within that range is 5%. The 12% max detonation was found just short of peak EGT.



Let's look at a low altitude, very high power (26.8-2700), very hot. There is no detonation at any mixture.



Let's go to a IO-540K on the FAA dyno at Hughes. The Big K is a standard detonation prone test subject, and it's used at GAMI/APS too.

Same setup as the above. Even with all temperatures at maximum, it doesn't tip into detonation until leaned to 50 ROP.

Now look at where we find max power, about 125 ROP.



Ok, so return to normal cruise power and temperatures. Show us the evidence validating this AI's "coaching".

Break.

Let's say you forget about operating advice, and just create a tool to collect and analyze. The examples above assume stock engines. However, we have folks with pumped CR. We have folks with lots of ignition advance. We have folks running car gas. And we certainly have folks with poor cooling. Can you create a tool to find the limits for their engine, rather than a blanket "beware this range"?

 

[jquayle]

Dan,

You're right, and the data you posted makes the point clearly.

I also went back and checked Busch's own text. He says the red box "disappears completely at 60-65% power for most engines" and that carbureted engines at 0.5 hp/in3 "can usually sustain moderate levels of detonation without damage." His own writing doesn't support the way I was using the concept.

I've updated the analyzer to reflect this accurately. It will no longer cite detonation risk from mixture position at cruise power settings. That wasn't supported by the data - yours or Busch's.

On your broader challenge (building a tool that finds the limits for a specific engine with pumped compression, ignition advance, mogas, or poor cooling) the honest answer is: not yet and probably not anytime soon. I'm not sure anyone has built that tool, including the professionals. What I can do is flag the data that would indicate those conditions are becoming a problem (sustained high CHTs, abnormal CHT/EGT relationships) without citing blanket rules that aren't grounded in evidence that I don't have.

That's the direction this is going. I appreciate you pushing on it. Your input is helping to shape this into a better tool.



Jeff

 

[RVbySDI]

sustained high CHTs, abnormal CHT/EGT relationships

These are “subjective” measures as stated. Defining what is a sustained “high” CHT, and “abnormal” relationships needs to be determined by some very objective data driven information. How, what, where is the AI going to base its decisions concerning those concepts?

 

[jquayle]

These are “subjective” measures as stated. Defining what is a sustained “high” CHT, and “abnormal” relationships needs to be determined by some very objective data driven information. How, what, where is the AI going to base its decisions concerning those concepts?

Steve,

Absolutely right. I've removed 'high EGT' warnings and am now only using them as a reference value. For example to see if someone is leaning in cruse by keeping the EGT value consistent during the climb.


I'd also like to mention that I appreciate all feedback on this project. This is very much a work in progress and I'm attempting to improve it by making corrections when findings or analysis is incorrect.

To those of you that have submitted logs in the past, you may want to try them again. There have been a lot of improvements and your results might look much different.

Also, I'd again like to point out the follow up question option. Please take advantage of it. It really adds another layer to the reporting.


Thank you,


Jeff