Changes to the efis datalog stream

[Etienne]

Hi all

This is the cat amongst the pigeons...

I'd like to find out if there's a need to create a version 2 of the datalog stream from the D-100, or the other efii

This poll is to find out what is used and wanted by those developing software that reads from the efis, and want to make use of all the latest developments being released in Sept.

Pick the fields you'd like to see in
the datastream over and above what's already there (you can choose more than one). I've left off the gps/sl30 pass-through because a simple bit of wiring will do the same thing.

EDIT --> The poll doesn't seem to be working - see my post below to see the suggestions: Agree/Disagree/Add your own!

 

[khorton]

Am I the only one that can't find this poll?  I've tried several different browsers, but no poll.  Maybe it is one of those Mac vs Windows things.

I am definitely interested in a way to get changes to the data stream.  Things I would like to see:

One more digit in the vertical g,

either the altimeter setting, or pressure altitude,

the correction to the pitch attitude (so I can compare data pitch data from different flights, in case the correction was changed).  Or, just spit out the raw pitch attitude, and I can make the correction when I process the data, and

OAT.

A selectable, slower data rate could also be useful (8 Hz is more than enough - 64 Hz is too much information).  This might facilitate putting more data elements in the data stream.  By all means, leave the default data stream at 64 Hz, the people who need it (I might need it someday, if I implement my idea of using the EFIS as the air data and attitude sensor for an autopilot).

 

[Etienne]

Nope, you're not the only one... It's wierd, because I definately did add the poll bit, and there's no longer an option to add a poll.

Arg.

Well here were my original suggestions, maybe we can just do this the old-fashioned way

• OAT
• Extra precision in HDG (0.1deg)
• Winds aloft
• What the bugs are set to
• QNH
• TAS

Regarding the 8Hz, that would be to slow for my needs (read "designing autopilot driven by gps and efis"), but obviously if the stream is already maxing out the baud-rate then 32Hz would probably be ok... Designers should use the time-stamp to avoid being affected by the update rate.

An extra digit in vertical and lateral G is also rather useful...

 

[Etienne]

Here we go for round 2...

Pressure altitude has already been implemented, but there are still some other changes I would like made to the data stream...

Dynon have found a way of increasing the number of fields without changing the frame rate or length of the message, by flipping between two values in the same position (like pressure altitude and qnh-fixed altitude).

On that note, the current implementation of that is 5 messages with the one, then 5 messages with the other. IMHO it would be better to have one message with each type.

The method would be able to handle the TAS/IAS values, but for the other suggestions, it would require extra data to be added to the stream.

There could be one field added for the bugs (which could cycle alt, then hdg, then air speed).

QNH can be calculated now by comparing the difference in pressure and actual altitude (help here would be appreciated).

Winds would be really great, but can also be calculated if you already have a gps connected.

OAT cannot be calculated, unless there is TAS available (but what a pain!).

As for the heading, internally, there is sub-degree precision, but it's not available in the datastream... It really would be a nice feature, as a 1-degree precision is quite jumpy.

So really, I'd suggest adding TAS (after the calibration table is applied ) at least, then it would be possible to solve a couple of the other fields externally, even if it's with great effort!

What say ye?
Etienne

 

[khorton]

QNH can be calculated now by comparing the difference in pressure and actual altitude (help here would be appreciated).

Are you looking for an equation so you can calculate QNH given pressure altitude and barometric altitude?  If so, I think I can probably hash one together for you.

 

[Etienne]

Are you looking for an equation so you can calculate QNH given pressure altitude and barometric altitude? If so, I think I can probably hash one together for you.

Yes please As far as I can tell, it's a very simple relationship - the difference between the two multiplied by some factor will give QNH, but I have looked and looked, and have yet to confirm that!

 

[khorton]

QNH = 29.9213 * (1 - (HP - H) / 145442.2)^5.255594

where QNH is in inches of mercury
HP is pressure altitude in feet
H is barometric altitude in feet

If you want QNH in hpa, then replace 29.9213 with the sea level pressure expressed in hpa.

 

[Etienne]

My word! Ok, so I was way off : Thanks very much, that's awesome

 

[khorton]

My word! Ok, so I was way off  : Thanks very much, that's awesome

Well, that formula can be approximated by a straight line for the normal range of QNH, as you will see if you plot it. The function has a very small curve in it, so the factor you would use for a linear approximation would depend on what range of QNH you were interested in. You only need the correct formula if you want the exact answer. How accurate a result do you need?

 

[Etienne]

the only thing I'm trying to do is reverse-calculate the QNH from the spread in baro altitude and pressure altitude in the datastream, as a work around if qnh isn't ever added to the stream...

I should be able to approximate it, and if it doesn't work well enough, well then, that's what math coprocessors are for

 

[Etienne]

There is another field I would like to see in the datastream, and that is horizontal acceleration. Vertical and lateral are already there as G's and slip, so it would be possible to switch between vertical and horizontal values...

 

[waiter]

The most important field is also missing from the wish list

VERSION or FIRMWARE BUILD number.

As Dynon continues to alter the data stream, its getting progressivly more difficult to write software that is compatable with all versions that may be in the end users hands.

My vote would be to impliment ALL the changes, but add a Build number in the header.

Waiter

 

[Etienne]

The most important field is also missing from the wish list

VERSION or FIRMWARE BUILD number.

As Dynon continues to alter the data stream, its getting progressivly more difficult to write software that is compatable with all versions that may be in the end users hands.

My vote would be to impliment ALL the changes, but add a Build number in the header.

Waiter

That's a very good point!

I hadn't thought of that one. Even better would be a datastream version number, so that if from one firmware upgrade to another the datastream doesn't change, then the datastream version won't change either...

 

[khorton]

What I would really like to see, is an user customizable data stream.  Using the PC support program, the user would select exactly which items he wanted, what resolution he wanted for each item, and what order he wanted them to be in.  Then he would select the desired data rate.  The PC support program would know what bandwidth was available, so it would not allow the user to select a data rate that was too high.  Users could create several different data stream formats - the active one would be selectable via a menu on the EFIS.

Creators of custom software could create specific data stream formats to best suit their needs.  They could provide users with a structured text file that defined the format, and the user could tell the PC support program to pull the data stream definition from this structured text file, to avoid the risk of him making a mistake as he attempted to replicate a complex data stream format.

Once the EFIS was hooked up the the PC support program, the customized data stream definitions would be loaded onto the EFIS, and now it would be selectable via a menu.  The user could select between the standard data stream, or one of the custom ones.  His selection would be remembered as the new default.

Allowing the user to create the data stream format avoids the problem of Dynon having to parse all the user requests and then try to define a new format that meets the needs of the highest number of users.  Simply give us the tools to define our own formats, and leave the rest to us.

 

[Etienne]

This is a response from Dynon previously on a related thread... I'm not sure a user-definable or even a user-selectable datastream is possible, considering what generates it, but there's nothing stopping once-off changes being made.

At this point we don't have any plans to change our output stream since we don't have the engineering resources to do it. We're always happy to listen to our customers, so please keep the comments coming, and we'll keep it on the list, but we're busy working on other things right now.

Dynon doesn't run an operating system on a PC processor like many other companies do, so adding things to our streams, changing data rates, or making the output selectable isn't a simple task. This archetecture gives us the reliability and fast boot times that you have come to expect from us though. The stream out from the EFIS comes from a real-time, stand-alone microprocessor that acts as our ADAHRS unit, so changing this is a pretty big task that carries a risk with it of causing a bug in the ADAHRS. As far as we know, we're the only company that outputs any data at all in a published format, so we're pretty ahead of the game here.

Also remember that we currently use the output of the EFIS to create the copy of the screen on the EMS, so we need to change both the parser in the EMS as well as the data output in the EFIS. It's a lot of work.

Once we have full DSAB out and the stream isn't used by us anymore, we might consider adding stuff. Keep letting us know what you want and hopefully we'll get to it some day, but we aren't making any promises today. Maybe someday we'll even be able to output in standard ARINC 429 format and you'll just be able to pull that if you want it.

One thing I'd personally be very interested in is what our customers are doing with all of this data. What kind of analysis do you use it for? What kind of displays are you designing? It may be better for our customers to put some of this functionality right in the unit rather than having you design it outside.

 

[dynonsupport]

Our story is still the same. We'd love to be able to accommodate every feature request, but given the size of our company, we have to make some tough decisions with respect to where we allocate resources. The data stream is tough to change technically, which is why it doesn't change very often.

We don't currently have plans to rev the data streams coming out of the product.