Version 1.5.1 of BlueEDM is available in the App Store as of now. This version brings many bug fixes. E.g.:
- the new flight export-to-JSON feature didn’t work correctly. It always exported the last flight contained in a file, regardless of which flight was actually selected for exporting.
- The value for which the DIFF warning occurs (i.e. where the EGT spread exceeds a certain limit) was incorrectly displayed as equal to the CHT warning limit.
- The DIFF value (EGT spread) was calculated wrongly, possibly leading to wrong results
Most importantly however, the new version now interprets values correctly, that represent failed (i.e. non available) sensor values. Let’s take a closer look at this.
JPI files stores the values of its sensors for each measurement in a compressed format. Basically, for each sensor the measured value is stored as the difference to the value for the previous measurement. If the value stays the same (i.e. the difference is zero), the value is omitted completely from the data package, thereby improving the compression ratio of the JPI file. A special case occurs, if a sensor value is present in the measurement but its value is zero, seemingly indicating a unchanged sensor value. That interpretation is wrong. Such values (present, but zero) in fact indicate measurements where a value for this specific sensor is not present, i.e. a failed sensor for this measurement.
Such values are now processed correctly by the EDM parser and are also present in the JSON export, under the „Failed Sensor“ field (an array with an entry for each failed sensor):
That helped me resolving a long outstanding question, of what happened during a flight from Odense (EKOD) to Mannheim (EDFM) in 2021, where the EGT for cylinder 1 dropped low on the EDM during flight and I actually declared an emergency to perform an emergency landing in Paderborn (EDLP). See Odense – Paderborn-Lippstadt, 20.8.2021, for the whole story (available only in German).
The open question was, whether this was an engine (cylinder) failure and the EGT-temperature really dropped low for that cylinder or whether this was a sensor defect. The experience from this flight, brought us to start downloading engine monitoring data from our EDM700. Actually I started the BlueEDM-project out of this (since one of the owners of DEEBU complained about having to take a laptop to the cockpit in order to download the monitoring data).
We uploaded the JPI-file to https://apps.savvyaviation.com/ and got the below graph for the EGT values. You can see a sharp drop of the EGT for cylinder 1 after around 02:15. Actually, the drop is not down to zero but to around 500 °F. The exactly constant value after that drop indicates unchanged EGT values, which in fact indicates something is wrong with the sensors. However, from the Savvy analysis there was no proof. This is due to the fact that the parser Savvy uses is not honoring the failed sensor fields from the JPI files. Such constant value in the JPI-file could have been due to the non-presence of the EGT value in the EDM output for the rest of the flight
When looking at the JSON output from BlueEDM for that same data, however, we can see the „Failed Sensor“-values for that time and the rest of the flight, represented by a zero value. The screenshot above is taken from that JSON data (here numbering of cylinders starts at 0). That finally proves that the drop of EGT was due to a failed sensor and not due to an engine failure.
A friend of mine (who interpreted the graph below correctly) mentioned that failure of EGT probes is quite common and EGT sensors have to be replaced more often than any other sensors.
BTW: After stopping the engine and starting again, the error was gone and EGT probes continued to work correctly up to the date