New GRT flight data analysis tools (Garmin and Dynon too, sorta)

[Skid]

Originally Posted by Canadian_JOY

Well, that's a great idea, but it will be an even better idea once I have a GRT engine monitor installed!

(I've got the hardware, the EIS-66R and a new Sport EX EFIS sitting on the shelf waiting to replace the currently installed dedicated engine monitor. Soon, soon...)

The remote EIS is not the same as the EIS 4000. I have an open ticket with Savvy analysis since November of 2019, still waiting for a resolution. They have been unable to process the data and stated they have been working with GRT to resolve the issue. I can open the csv files with this tool however.

[622BH]

For those who use AFS EFIS - after downloading the ALD files simply change the ALD to CVS; confirm you want to use CVS, then any spreadsheet program will work with it un-impeded. Mac as well as PC systems won't know the difference.
Therefore, this program can work with "ALD" files just fine - after you "convert" to CVS.

[Canadian_JOY]

Originally Posted by Skid

The remote EIS is not the same as the EIS 4000. I have an open ticket with Savvy analysis since November of 2019, still waiting for a resolution. They have been unable to process the data and stated they have been working with GRT to resolve the issue. I can open the csv files with this tool however.

Skid - would you be able to elaborate on this point, please? In what ways are the data from the EIS-66R different from the EIS4000? I (clearly mistakenly) believed their data streams would be the same since they provoke the same display response on the GRT EFIS displays.

Thanks in advance for your patient sharing of information.

[flyvans.com]

Originally Posted by 622BH

For those who use AFS EFIS - after downloading the ALD files simply change the ALD to CVS; confirm you want to use CVS, then any spreadsheet program will work with it un-impeded. Mac as well as PC systems won't know the difference.
Therefore, this program can work with "ALD" files just fine - after you "convert" to CVS.

totally aware about that. changing the filename extension does exactly zero to its content. simply renaming it as csv doesn't do the trick here. it's still a comma separated value file with a custom header line, then a custom column index line and then data.
and neither the order of the columns nor the column header names in AFS are exactly the same as with GRT.
you do not want to map the data e.g. by column index order and then end up with the wrong data in inappropriate data fields. this will screw up all the valuable graphics and the other essential processing which makes this tool special.

[Skid]

Originally Posted by Canadian_JOY

Skid - would you be able to elaborate on this point, please? In what ways are the data from the EIS-66R different from the EIS4000? I (clearly mistakenly) believed their data streams would be the same since they provoke the same display response on the GRT EFIS displays.

Thanks in advance for your patient sharing of information.

Savvy never explained how the data was different just that they (Savvy) was unable to read it. The response I received in January was they were working with GRT to resolve the issue. I asked for an update from them about a month ago but due to the shutdowns around the county I have to assume they are behind like everyone else. I have the R66 connected to my GRT Sport SX and it is much easier to use as all the limits etc. are set on the EFIS instead of having to go through the pages on the EIS 4000 it replaced.

[RV-14E]

Greetings.

Let's take a look. Send me an example file. Contact info is in the spreadsheet.

Originally Posted by flyvans.com

great tool!

would you consider adding *.ALD support for advanced flight systems EFIS?
Nothing else than a specific csv file format with header.

i'm using another open excel based analysis tool so far, but yours appears to be much more refined! and more recent and with a much improved google earth integration... nice job!!!

a typical header, fields and first data point line look like this (the <LINEBREAK> are added by me to make it more clear):

AF-4000s Software Version: S8.8.40-MV15     SN: 61041 <LINEBREAK>
DATE, TIME, ALTITUDE, AIRSPEED, BATVOLTS, VOLTS, OAT, BACKVOLTS, VERTSPEED, FUEL_COMP, RPM, MANIFOLD, FUEL_PSI, FUEL_FLOW, AMPS_SHUNT, AMPS_HALL, OIL_PSI, OIL_TEMP, CARB_TEMP, TANK_1, TANK_2, EGT_1, EGT_2, EGT_3, EGT_4, CHT_1, CHT_2, CHT_3, CHT_4, HP, ELEV_TRIM, AIL_TRIM, FLAP_ANG, FLIGHT_TIME, TACH_TIME, HOBBS_TIME, TODAY_TIME, INPUTS_123, PITCH, ROLL, HEADING, SLIP, G_METER, AHRS_STATUS, LATITUDE, LONGITUDE, GROUND_SPD, TRACK_DTRUE, TRACK_DMAG, BARO<LINEBREAK>
12/15/19,11:18:09, 2070, 78, 8.4, 14.1, 11, 3.1, -820, 16.8, 1163, 7.7, 10, 1.9, 0, 149, 52, 177, 5, 9.2, 15.6, 738, 684, 728, 723, 224, 229, 238, 224, 0, 0, 0, 0, 0.04, 468.0, 605.2, 1.2, 000, -13.86, 2.1, 96.9, 0.03, 0.9, 0x0100, 47.45226, 8.24511, 97, 78, 75, 29.79<LINEBREAK and next data point>

another "specialty" with AFS is that it offers to record the logs to files simply by extracting the data from non-volatile memory, looking at a certain elapsed time back from NOW in hours / and decimal hours.
Upside is you can potentially retrieve large amounts of data without having to configure anything / setup recording, even going back for several hours.
But a side effect of this mechanism is that when you retrieve every flight just before shutdown (as part of the shutdown checklist as we do), the file will usually start with a short artifact of the previous flight (usually another date/time or hours before on the same day)
When you download, let's say 1.4hrs (value gets preset by EFIS and conservatively covers the duration of the flight just ending), at the very beginning of the file you have to expect up to a few minutes of data that really belongs to another flight before.
If the toolchain could also somehow filter that out, it would be awesome! Basically forward to the first "jump" in date/timestamps by more than a few seconds and only then start using the data.
Also, the user can configure his system to by default log at different intervals. We log at 1s, but it is possible to see other intervals in an *.ALD log file. But they will always be at a fixed interval and the absolute timestamp will show what rate is used.

i certainly could hack something together, but there is bigger benefit for all if you could add that support in the "main branch" of your tool ;-)

thanks for your work!

bernie

[RV-14E]

You can find my free public domain Microsoft Excel-based software here and view much of the information in this and the initial posts with higher resolution images and embedded videos.

Greetings. My data analysis program has been updated to include bug fixes, user experience improvements, code optimizations and speed improvements.

Garmin and Dynon users do not have additional features. You can still use your CSV files to view your data and create a Google Earth KMZ file with several methods to view your data.

However, several new features have been included for GRT users (the main audience for my program):

First, the most significant:
A master database of all aircraft identified by your ADS-B receiver can be maintained.

1. Automatically create a master database of all aircraft identified by ADS-B.
? Count number of unique dates each aircraft was found (a "hit").
? Track dates of each "hit".
? Single click access to all dates any aircraft was identified.
? Independent master databases for each aircraft you fly (based on its registration). Useful if you fly more than one aircraft.
? A new yellow tabbed sheet is maintained to show the records in the master database.
? Each aircraft you fly gets its own tab.

2. Aircraft list includes accurate silhouette of aircraft type.
? The aircraft-to-silhouette mapping can be exported and imported to support updates to the mapping.
? Automatically create a list of aircraft for which a silhouette could not be resolved.
? This list can be used to manually update the mapping.
? After this list grows significantly, you can send it to me so I can update the mapping.


Additional features I added:

? Magnetic variation is calculated using the IGRF model (the same model the EFIS uses) when the GPS source does not provide it. This allows wind vector to be now calculated under all conditions.

? Analog input decoding from LOG file now supported for HXr, HX, Horizon HS and Horizon WS. Requires EFIS PIC calibration data from setup screen.

You can find the minutiae of all of the changes on the "Changlog" tab. My contact information is on the "Welcome" tab.

I am especially grateful for one of my users, let's call him "R", for helping me test the code. His attention to detail, willingness and responsiveness are greatly appreciated.

Example of aircraft listing showing silhouettes.



Example showing "hits" from the master database of all aircraft identified.



You can find my free public domain Microsoft Excel-based software here and view much of the information in this and the initial posts with higher resolution images and embedded videos.

[RVProcess]

Skid - I’ve been uploading my GRT .csv file to Savvy for a couple of years now with no problems.

[RV-14E]

You can find my free public domain Microsoft Excel-based software here and view much of the information in this and the initial posts with higher resolution images and embedded videos.

Greetings.

v4.1 released. In addition to the usual myriad of code improvements and bug fixes, here are the major changes:

1. For GRT users
? LOG file: Wind vector thresholds available to suppress calculation of the vector (e.g., during aerobatics or high rate-of-change maneuvers).
? LOG and CSV files: Data smoothing available for analog and EIS aux inputs (useful for noisy inputs like fuel floats and Hall effect sensors).
? List of LOG files processed provided, including start, end and duration times including how long it took the EFIS to flush each file (representing missing flight data).
? ADS-B:
-- Can now decode ADS-B surface position reports so you can see aircraft and vehicles move on the ground. KDEN ground movement video from a flight near that airport.
-- Can sort by callsign for those aircraft whose callsign is an N-number. This will favor putting private, U.S.-registered aircraft at the top of the list so you don't have a bunch of Boeings and Airbuses at the top.
-- Master database:
---> Added editing features.
---> Can import master databases so you can share and compare among friends.
---> You can now compare two or more master databases to find aircraft common to them. This lets you determine if two different airplanes you fly or databases between friends have seen ADS-B reports from the same aircraft.

2. For non-GRT users:
? AFS users
-- Support added. Though I'm not clear on what version(s) may be supported.
? Dynon and AFS users:
-- Can select from a single flight when multiple flights are contained in your CSV/ALD file.
? Beast Raw and GDL90 binary (Stratux, FlightRadar24, FlightAware, ADS-Bx) users:
-- Much more robust code.
? All users:
-- Distance calculation also shown in km.
-- The full suite of support now include AFS, Garmin, Dynon and my favorite, GRT, having an expansive data analysis capability only available to GRT users thanks to willingness to share their data formats.

A full accounting of all the changes are found on the "Changelog" sheet.

You can find my free public domain Microsoft Excel-based software here and view much of the information in this and the initial posts with higher resolution images and embedded videos.

[RV-14E]

Bernie kindly sent me some ALD files to work with and graciously tested my new code. AFS support has been added. However, I'm not clear which versions of AFS' .ALD files are supported, so for those that try it and it doesn't work, please let me know. My contact information is on the "Welcome" sheet.

Note: For AFS users, all of your options are on the "FDL - Options" sheet except for the wind vector filtering options, which are located on the "LOG - Options" sheet for now (since GRT LOG file users share those options).

Originally Posted by flyvans.com

great tool!

would you consider adding *.ALD support for advanced flight systems EFIS?
Nothing else than a specific csv file format with header.

i'm using another open excel based analysis tool so far, but yours appears to be much more refined! and more recent and with a much improved google earth integration... nice job!!!

a typical header, fields and first data point line look like this (the <LINEBREAK> are added by me to make it more clear):

AF-4000s Software Version: S8.8.40-MV15     SN: 61041 <LINEBREAK>
DATE, TIME, ALTITUDE, AIRSPEED, BATVOLTS, VOLTS, OAT, BACKVOLTS, VERTSPEED, FUEL_COMP, RPM, MANIFOLD, FUEL_PSI, FUEL_FLOW, AMPS_SHUNT, AMPS_HALL, OIL_PSI, OIL_TEMP, CARB_TEMP, TANK_1, TANK_2, EGT_1, EGT_2, EGT_3, EGT_4, CHT_1, CHT_2, CHT_3, CHT_4, HP, ELEV_TRIM, AIL_TRIM, FLAP_ANG, FLIGHT_TIME, TACH_TIME, HOBBS_TIME, TODAY_TIME, INPUTS_123, PITCH, ROLL, HEADING, SLIP, G_METER, AHRS_STATUS, LATITUDE, LONGITUDE, GROUND_SPD, TRACK_DTRUE, TRACK_DMAG, BARO<LINEBREAK>
12/15/19,11:18:09, 2070, 78, 8.4, 14.1, 11, 3.1, -820, 16.8, 1163, 7.7, 10, 1.9, 0, 149, 52, 177, 5, 9.2, 15.6, 738, 684, 728, 723, 224, 229, 238, 224, 0, 0, 0, 0, 0.04, 468.0, 605.2, 1.2, 000, -13.86, 2.1, 96.9, 0.03, 0.9, 0x0100, 47.45226, 8.24511, 97, 78, 75, 29.79<LINEBREAK and next data point>

another "specialty" with AFS is that it offers to record the logs to files simply by extracting the data from non-volatile memory, looking at a certain elapsed time back from NOW in hours / and decimal hours.
Upside is you can potentially retrieve large amounts of data without having to configure anything / setup recording, even going back for several hours.
But a side effect of this mechanism is that when you retrieve every flight just before shutdown (as part of the shutdown checklist as we do), the file will usually start with a short artifact of the previous flight (usually another date/time or hours before on the same day)
When you download, let's say 1.4hrs (value gets preset by EFIS and conservatively covers the duration of the flight just ending), at the very beginning of the file you have to expect up to a few minutes of data that really belongs to another flight before.
If the toolchain could also somehow filter that out, it would be awesome! Basically forward to the first "jump" in date/timestamps by more than a few seconds and only then start using the data.
Also, the user can configure his system to by default log at different intervals. We log at 1s, but it is possible to see other intervals in an *.ALD log file. But they will always be at a fixed interval and the absolute timestamp will show what rate is used.

i certainly could hack something together, but there is bigger benefit for all if you could add that support in the "main branch" of your tool ;-)

thanks for your work!

bernie