hi all,
I have this EDM 900 that has been an amazing instrument during flight. Many times I pull all the data log records for post flight analysis, but it either requires a windows based EZtrends (provided by JPI) or one can use the online savvyanalysis webpage.
The EZtrends while nice I don't believe is further developed/expanded on. It is windows based.
The savvyanalysis, I noticed there are quite some bugs with it. You could look at it from a visual perspective, but you can't rely the timebase or actual values. I tried to give that input and some solutions that were left unresponded. So it was time to DIY
I really wanted a utility to convert the log file pulled from the JPI into a CSV for my own plotting and analysis. I finally got to it and around it (thank you retirement. It was several nights of coding fun staring at hex numbers and addresses. Gotta love it
Download a copy here
I was fortunate enough to get connected with the 2 most senior engineers at JPI (Derek and Tai and THANK you once again!), to exchange understanding of the files produced and how to dissect them. Even in the functional specification, of the call it original intent, the implementations didn't match what I actually found during development!
Anyways long story short is that I have now a rock solid utility for LNX, OSX and Windows that can parse the file, display the flight records it captured and allow you to export all parameters recorded from the EDM into a CSV with a user defined selection of what you'd like to capture in the CSV.
I cross compiled it for windows on a mac (mbp2) to an exe but I couldn't test it myself yet. The LNX and OSX versions are solidly tested.
USAGE:
- Execute the utility as is, it will bark an error that it is missing a file to process and show a help.
Normal usage would be: ("platform" is osx,exe,lnx)
1) invoke jpi_<platform> -d
to dump all the flight records it found in the file with their associated date and time as recorded by the EDM (in your timezone)
2) invoke jpi_<platform> -f <U_datedownloadedfromedm_.JPI -p <recordID from the first column, or call it record number>
to create a CSV record with the fields defined in the jpi.cfg file. If not specified a default set of columns/variables is produced.
if you like to see what the utility does during processing invoke it with:
jpi_<platform> -f <file> -p <recordID> -n 1 -x 3
this will process one data record (-n) from the requested recordID/flight (-p) with maximum debug detail (-x)
I am working with JPI once more to understand the timeline of the records, as while the record interval (6sec by default) would produce 10 records per minute, this does not seem to be the case always. There is a variable (SNAP) that seems to affect the record interval (you'll see it in the debugging). (this is also sw bug in the savvy webpage), besides time, besides actual values, it seems to be a business model to have you request analysis for a fee). With this tool and this community, you can do it yourself!
The utility would produce a CSV file for the flight you requested and you can process that with Excel or similar to produce whatever graph you want.
I am storing everything in a (mysql) database, Using a TSDB (timeseries database) like INFLUX, you can use grafana very easily and or google charts for display of whatever correlation I'd like to see.
Use cases:
- how does my MAP/RPM with fuel flow affect the EGT/CHT and have some ability to enhance my leaning procedures.
- Correlate OAT with CHT and EGT to see if there is (high density) altitude performance problems potentially.
- Detect spark plug issues early on (you'd see inverted CHT+/EGT- type of graphs for that cyl).
- Identify voltage (regulator) possible problems, a regulator or alternator on the way out
- Detecting OIL flow, temperature, pressure, leaks very early on.
One BIG BIG BIG thing to understand also, one of my concerns earlier on, was some parameters can show flat lines or some show small sawtooth behavior. I was wondering if I had a bad sensor or a problem with the engine. The thing is however that the EDM will only record _delta's_ AND not in every record either!
Its record implementation is almost like an old school audio CD delta sigma encoding. (Apparently this was done to save a few bytes like we still have 8k RAM or so). Different discussion It also sometimes doesn't record every variable for record (making it look flat).
Depending on what variable you're looking at this sawtooth is likely ok (eg fuel pressure is not constantly flat 21.1, it can be 19.9-21.2 something like that).
In this version the sum of data records is not yet indicative of the actual duration of the flight that I still want to enhance when I reverse engineer that part, right now at least it provides for solid data logging from your engine.
It also helps in adjusting your K-factor. Which to me is critical to balance and match the fuel quantity left in the wings, vs the fuel-flow/time of what is reported USED/REMAINING in your wings by the EDM. USED/REMAIN are independently calculated values. A next version will report an auto correct recommendation on the K factor also, which it looks like in my plane I need to adjust every so many flights.
Would welcome any inputs/requirements/suggestions you may have!
cheers!
xander
I have this EDM 900 that has been an amazing instrument during flight. Many times I pull all the data log records for post flight analysis, but it either requires a windows based EZtrends (provided by JPI) or one can use the online savvyanalysis webpage.
The EZtrends while nice I don't believe is further developed/expanded on. It is windows based.
The savvyanalysis, I noticed there are quite some bugs with it. You could look at it from a visual perspective, but you can't rely the timebase or actual values. I tried to give that input and some solutions that were left unresponded. So it was time to DIY
I really wanted a utility to convert the log file pulled from the JPI into a CSV for my own plotting and analysis. I finally got to it and around it (thank you retirement
. It was several nights of coding fun staring at hex numbers and addresses. Gotta love it Download a copy here
I was fortunate enough to get connected with the 2 most senior engineers at JPI (Derek and Tai and THANK you once again!), to exchange understanding of the files produced and how to dissect them. Even in the functional specification, of the call it original intent, the implementations didn't match what I actually found during development!
Anyways long story short is that I have now a rock solid utility for LNX, OSX and Windows that can parse the file, display the flight records it captured and allow you to export all parameters recorded from the EDM into a CSV with a user defined selection of what you'd like to capture in the CSV.
I cross compiled it for windows on a mac (mbp2) to an exe but I couldn't test it myself yet. The LNX and OSX versions are solidly tested.
USAGE:
- Execute the utility as is, it will bark an error that it is missing a file to process and show a help.
Normal usage would be: ("platform" is osx,exe,lnx)
1) invoke jpi_<platform> -d
to dump all the flight records it found in the file with their associated date and time as recorded by the EDM (in your timezone)
2) invoke jpi_<platform> -f <U_datedownloadedfromedm_.JPI -p <recordID from the first column, or call it record number>
to create a CSV record with the fields defined in the jpi.cfg file. If not specified a default set of columns/variables is produced.
if you like to see what the utility does during processing invoke it with:
jpi_<platform> -f <file> -p <recordID> -n 1 -x 3
this will process one data record (-n) from the requested recordID/flight (-p) with maximum debug detail (-x)
I am working with JPI once more to understand the timeline of the records, as while the record interval (6sec by default) would produce 10 records per minute, this does not seem to be the case always. There is a variable (SNAP) that seems to affect the record interval (you'll see it in the debugging). (this is also sw bug in the savvy webpage), besides time, besides actual values, it seems to be a business model to have you request analysis for a fee). With this tool and this community, you can do it yourself!
The utility would produce a CSV file for the flight you requested and you can process that with Excel or similar to produce whatever graph you want.
I am storing everything in a (mysql) database, Using a TSDB (timeseries database) like INFLUX, you can use grafana very easily and or google charts for display of whatever correlation I'd like to see.
Use cases:
- how does my MAP/RPM with fuel flow affect the EGT/CHT and have some ability to enhance my leaning procedures.
- Correlate OAT with CHT and EGT to see if there is (high density) altitude performance problems potentially.
- Detect spark plug issues early on (you'd see inverted CHT+/EGT- type of graphs for that cyl).
- Identify voltage (regulator) possible problems, a regulator or alternator on the way out
- Detecting OIL flow, temperature, pressure, leaks very early on.
One BIG BIG BIG thing to understand also, one of my concerns earlier on, was some parameters can show flat lines or some show small sawtooth behavior. I was wondering if I had a bad sensor or a problem with the engine. The thing is however that the EDM will only record _delta's_ AND not in every record either!
Its record implementation is almost like an old school audio CD delta sigma encoding. (Apparently this was done to save a few bytes like we still have 8k RAM or so). Different discussion
It also sometimes doesn't record every variable for record (making it look flat).Depending on what variable you're looking at this sawtooth is likely ok (eg fuel pressure is not constantly flat 21.1, it can be 19.9-21.2 something like that).
In this version the sum of data records is not yet indicative of the actual duration of the flight that I still want to enhance when I reverse engineer that part, right now at least it provides for solid data logging from your engine.
It also helps in adjusting your K-factor. Which to me is critical to balance and match the fuel quantity left in the wings, vs the fuel-flow/time of what is reported USED/REMAINING in your wings by the EDM. USED/REMAIN are independently calculated values. A next version will report an auto correct recommendation on the K factor also, which it looks like in my plane I need to adjust every so many flights.
Would welcome any inputs/requirements/suggestions you may have!
cheers!
xander
