Developer Opportunity

[Boatguy]

The diagnosis of every Austro engine problem and ECU failure begins with "we'll need to pull the logs". The problem of course is that it's the rare Austro engined aircraft owner who has a service center on their home field. The drill is that the airplane either needs to get to a service center, or someone flies out to the airplane. If someone comes to the plane, they have no idea what parts to bring because they don't know what is wrong.

Fear of being AOG and 800nm from the nearest service center is well grounded and real.

What Austro should have made available a long time ago is an Austro Wizard iPad app. Given their current hostility and lack of interest in communicating with to owners, I don't expect it to arrive anytime soon.

The app would not need to mirror the Austro Wizard (graphics, statistics, etc.). Basic requirements:

- download the logs so they can be emailed to a service center
- display and decode errors (table is in the ops manual)
- clear latched errors
- "Live" mode display of realtime data

There is an open source CAN-USB adapter. PEAK, who makes the driver distributed by Austro has a number of related CAN products and expertise. A search on CAN bus software with Perplexity identified 20 developers. There is at least one iOS app under development (for Tesla). It might be necessary to reverse engineer some of the protocol if there are Mercedes proprietary commands.

I paid $800 for the dongle. An off the shelf CAN to USB adapter is about $200.

As of 2021 there were about 300 privately owned Austro engined aircraft. That number should now be at least 500-600.

I think every Austro engined aircraft owner would be willing to spend $500 on an app if they already own the dongle, and $1,000 for an app+dongle bundle.

No developer will retire on that, but it would certainly pay for somebody's college education and probably a regular gross revenue of $50K - $100K a year going forward for at least 5-10yrs.

I haven't written any code for 40yrs so it won't be me. Anyone have an interest? If there is a credible developer who would take it on, my guess is we could pretty easily collect $30K to fund some development cost. I'd commit $1,000.

[michael.g.miller]

I agree, this would be a great addition. I write lots of code every day (and fly on the weekends) so don't really have the mental bandwidth to do this.

Another awesome feature would be if it could analyze trends and report the likely reason for common ECU failures (e.x. Wastegate Actuator failure, Propeller Governor failure).

[nickname]

I'm interested and may start working on something myself. Might have questions for the experts. My dongle arrives next week so I can start tinkering.

[ingramleedy]

While it might be possible to decode the CAN bus directly from the serial port (which is really just a CAN interface) and figure out what commands, the austro application further formats and saves it into its file format, which I suspect are also encrypted.

There are many projects where you can hook up a Arduino to CAN bus, and with an ESP32 it has everything built in including bluetooth. You could then connect to an IOS app and send these raw logs.

However for the austro app to digest these raw logs on the receiving end, the data/file would have to be converted into its file format so it can load it and show you the results, which as far as I know is unknown. If encrypted would be even harder to decode. Has anyone tried to decode the saved files?

--Ingram

[Boatguy]

While it might be possible to decode the CAN bus directly from the serial port (which is really just a CAN interface) and figure out what commands, the austro application further formats and saves it into its file format, which I suspect are also encrypted.

Good point, though unverified. I don't know why anyone would want to encrypt them.

We don't know how extensively Austro modified the ECU s/w. Did they just change some parameters, or did they make more fundamental changes in the code? I tend to think the former.

There are a number of Mercedes engine diagnostic tools for sale at Amazon for less than $200. Also a number of other links from a search for Mercedes diagnostic software which offer free downloads, software for a fee, etc.

It seems reasonable that Mercedes engine diagnostic software could access the ECU's and/or read the files. Anyone know a Mercedes mechanic?

Here is a set of Austro logs if anyone wants to take a look.

https://1drv.ms/f/s!AvDxwIigp7Le8DnXt2W ... l?e=k4L0Fh

In any case, just displaying the fault codes would be a great first step. It's crazy that an Austro has to sit at an airport, AOG, until someone comes out and accesses the ECUs to find out what's happening.

[ingramleedy]

Code: Select all

Since AE300-Wizard version 1.2.0.xxx data files downloaded from the ECU are saved in a 
new compressed and encrypted format (“.ae3” file extension). This reduces the file size 
dramatically (about 1/10th of the size of the previous XML format) and enhances privacy of 
the data contained. These two factors make it easier to transfer files produced by the 
AE300-Wizard via the standard e-mail systems used on the internet.

The AE300-Wizard app according to the user guide saves in a compressed and encrypted format (“.ae3” file extension) for offline analysis using the AE300-Wizard or other tools.

In order to get the information to the a 3rd party so they can digest the data in their own AE300-Wizard app, we'd need to be able to re-create the .ae3 files.

Maybe someone has some inside at Diamond/Austro to get the encryption cipher and decryption keys?

-Ingram

[Boatguy]

Good catch!

It's not clear whose privacy they are protecting. Three hours of data is only about 1MB so compression was a waste of code. Creating a proprietary format seems pretty stupid at this point. I doubt Austro is going to share their compression algorithm or cipher/decryption keys

But does that imply that the data stream from the ECU is in XML? That would mean it's not too challenging to display which might make the Live mode much easier.

Even just being able to display / decode error codes would be a huge benefit. I think most of us fly with an iPad active or nearby. Not needing to always have a computer onboard would be a big relief.

[Ed McDonald]

Russ,

Great idea. With other aircraft I have used Savvy Analysis with great success. I asked them about the Austro’s and they have no capability, probably because of the small market size and the data acquisition/rights issue.
I think this initiative would be an excellent fit for the Diamond Pilots Association. As we saw with the owners survey, DPA can do some good work with limited resources. DPA does have some money in the account that can be allocated to this. If any person or organization can get through to Diamond or Austro on accessing the data or the encryption code, it would be DPA as opposed to individuals- I will state, however, that Diamond’s track record of honouring their agreement has been less than impressive.
I will raise this with the DPA executive. DPA is meeting with Diamond at Oshkosh and this could be put on the agenda.

[ingramleedy]

Well --- some success in decompressing and decrypting the file .ae3 files. Was able to disassemble and create some powershell scripts to get me this far. This is what the XMLs and formats look like below:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<RECMAN_HEXDUMP_DATLOG>
	<!--Description of Logfile-->
	<FILE_ID>
		<FILE_NAME>DataLog_20240613.ae3</FILE_NAME>
		<FILE_CREATION>
			<DAY>13</DAY>
			<MONTH>06</MONTH>
			<YEAR>2024</YEAR>
			<HOUR>20</HOUR>
			<MINUTE>58</MINUTE>
			<SECOND>27</SECOND>
		</FILE_CREATION>
	</FILE_ID>
	<!--Description of Wizard-->
	<SW_ID>
		<SW_NAME>AE300-Wizard</SW_NAME>
		<SW_VERSION>1.3.20.451</SW_VERSION>
		<SW_VERSION_ECU>ECU_VER_33_07</SW_VERSION_ECU>
		<SW_INSTALLATION>
			<DAY>not set</DAY>
			<MONTH>not set</MONTH>
			<YEAR>not set</YEAR>
		</SW_INSTALLATION>
	</SW_ID>
	<!--Description of Wizard-User-->
	<USER_ID>
		<USER_COMPANY>DRAGON</USER_COMPANY>
		<USER_NAME>DRAGON</USER_NAME>
		<USER_LOGIN>ingra</USER_LOGIN>
		<USER_NUMBER>ingra</USER_NUMBER>
	</USER_ID>
	<!--Description of Engine-->
	<ENGINE_ID>
		<ENGINE_TYPE_A>E4-A</ENGINE_TYPE_A>
		<ENGINE_TYPE_B>E4-A</ENGINE_TYPE_B>
		<ENGINE_SERIAL_A>E4-A-06551</ENGINE_SERIAL_A>
		<ENGINE_SERIAL_B>E4-A-06551</ENGINE_SERIAL_B>
		<ENGINE_TIME_A>122.60 h </ENGINE_TIME_A>
		<ENGINE_TIME_B>122.60 h </ENGINE_TIME_B>
	</ENGINE_ID>
	<!--Description of EECU-->
	<EECU_ID>
		<EECU_TYPE>E4A-92-000-000</EECU_TYPE>
		<EECU_SERIAL_A>005100025482261122092532</EECU_SERIAL_A>
		<EECU_SERIAL_B>005100025482261122092532</EECU_SERIAL_B>
		<EECU_HWREV_A>AE</EECU_HWREV_A>
		<EECU_HWREV_B>AE</EECU_HWREV_B>
		<EECU_SWREV_A>VC33_1_07_26 (26.05.2023)</EECU_SWREV_A>
		<EECU_SWREV_B>VC33_1_07_26 (26.05.2023)</EECU_SWREV_B>
		<EECU_TotTimeECUA>139 h 0 m 6 s</EECU_TotTimeECUA>
		<EECU_TotTimeActECUA>61 h 34 m 12 s</EECU_TotTimeActECUA>
		<EECU_TotTimeECUB>139 h 0 m 35 s</EECU_TotTimeECUB>
		<EECU_TotTimeActECUB>61 h 2 m 4 s</EECU_TotTimeActECUB>
		<EECU_RTC_ECUA>13.06.24 21:01:59</EECU_RTC_ECUA>
		<EECU_RTC_ECUB>13.06.24 21:01:40</EECU_RTC_ECUB>
	</EECU_ID>
	<!--RecMan Status ECU A-->
	<STATUS ENTRY_CNT="1462"
	        ACTIVE_EVREC="2"
	        ACTIVE_DATLOG="134"
	        xmlns="A"/>
	<!--Section RecMan Sectors ECU A-->
	<SECTORS xmlns="A">
		<SECTOR>
			<ID>16</ID>
			<DATA>
				<B>97</B>
				<B>246</B>
				<B>8</B>
				<B>208</B>
				<B>3</B>

Also good resource on CAM BUS here https://www.csselectronics.com/pages/ca ... o-tutorial


@russ I was not able to get your .ae3 files to work. Would you send me your "MEA.Misc.dll" in your AE wizard, want to check and see if the encryption keys are different.

[ingramleedy]

Russ,

I used dotPeek to disassemble the Microsoft .NET .dlls of AEWizard files. This allows you to look thru their code, which is quite complex. Poking around was able to find the encryption keys and methods to reverse the .ae3 files into their original XML files. The XML files are generated from the AEWizard app, not from the ECU. The ECU uses CAM bus protocol, where the AEWizard sends commands to the network and gets results back from the ECU thru the serial port. A side note, there is some logic to detect the type of dongle attached, which I assume is used to control how AEWizard restricts what it able to do or even work at all. I haven't tested the raw CAM bus, but I assume its pretty standard, just would need some software to digest and command the CAM bus network to the ECUs.

To create IOS app, we'd need to understand the CAM bus ECU commands that AEWizard is requesting and then format that into the .ae3 schema, send it to the 3rd party (mechanic) where they could open in their own AEWizard. There is no documentation, so this would be a painful process, but possible.

I'm not excited about playing around with the ECUs on a real airplane nor the time it would take to possibly figure this out for such a small market. But it is a great learning experiment.

Attached are the pure XML files from Russ' logs that AEWizard actually creates before compression and encryption.

Austro Logs XML.zip

(1.21 MiB) Downloaded 859 times