François Badoux wrote:

Paul, maybe you can send this more compact document to the network?...

That is much better. I am not a fan of doc files.

300K is about our limit.

Most efficient are plain text and gif files.

That CAN network impresses the heck out of me.

As I understand it CAN can send out a whole bunch of real time

info on the engine that can be captured on a notebook computer's

hard disk. Just like OBD II. I am impressed. Pretty ambitious software

project for such a small company like Mistral. I know the big car

companies tens of thousands on this sort of thing. Unless of course

you found this software off the shelf someplace. What engine parameters

can be output in real time? Tracy and I talked about this a while

back and I am not sure if his unit can now do this.

Paul Lamar

Francois Badoux wrote:

Well Paul, you certainly can't buy this software off-the-shelf... especially

in an aviation certifiable version.  It's the result of 18-month of

development with 2 softqare engineers (one of them a PhD and a real wizard)

and 1 hardware engineer full-time.  The CAN system, on the other hand, is a

standard feature just as on your OBD II.  You have to remember that the CAN

sends "packets" of coded information when it's got the capacity to do it.

Therefore it's not real-time (for tiny fractions of a second, though).

Every engine parameter can be transmitted over the CAN EXCEPT RPM and crank

angle indication which MUST BE real time. Ignition and injection actuations

must also be real time.  Everything else can be carried over the CAN.

The CAN greatly simplifies cabling, especially in a twin or a pusher.  You

have only 2 wires (actually 4 for redundancy), instead of a couple of

dozens, to transmit information between the engine, the ECUs and the pilot

display.

I must compliment my electronics team for a great job.  They clearly

overdelivered on my expectations.  And they did it below budget and within 6

weeks of an aggressive deadline.

Francois

I had no idea you had sponsored such an ambitious and sophisticated project.

When you buy a new Lycoming or Continental engine you get nothing. The new Power

Sport did something similar but I never examined it closely as they refused to

sell parts to the experimental market. Fatal mistake IMHO.



Those new color transflective TFT displays are also wonderful. Robin got

a new Blackberry with a color transflective TFT and it is very readable under

all conditions.



The OBD II in my RX8 sends out RPM data along with the exact time to the nearest

thousands of a second. Since the RPM changes slowly in an aircraft engine

I think you should send out RPM. True... nothing is real time in the strictest

sense as a single chip processor can only do one thing at a time.



There is real time and then there is real time. A thousandth of a second

is sufficient for our purposes I would guess. Most single chip processors now a days

can do 10,000 steps or more in a thousandths of a second. Many times more with

the type of processor used in your PC but nobody uses those in engine

monitors or engine control computers I suspect. Programers also program

them in bloated modular C which is much much slower than assemble language. Just

for academic reasons what type of processor are you using?



Here is sample of what my RX8 OBD II puts out. Notice it sends out a new

data set ever tenth of a second or so. This was a 0 to 100 MPH acceleration

run where the RPM is changing rapidly.



A similar sample from your system would be a great demonstration and sales tool of

what your system can do.



BTW the RX8 also has a CAN network and Racing Beat is using that instead

of OBD II for engine development



Paul Lamar

Paul,



Actually we did the DEM development in-house.  FYI: It started in mid-2001, being outsourced to a French company doing controllers for car racing and for LPG vehicles.  When our project was 85%
complete, the company went bust.  The only way not to lose everything was to purchase the assets of the company, which we did. We then sold the automotive-related assets, which we didn't need, to a
Belgian company.  We hired a couple of electronics engineers to finish the work.  They completed it and this system, DEM Generation I, is the one flying on the Arrow.  It works just fine and we had
no bug whatsoever, except for some interferences due to insufficiently shielded cabling.  However, we found out that 

a) the NEC processor was not powerful enough to allow further development, and b)

the assembler software was a jungle that had evolved over a decade and was very badly referenced.  

We therefore decided NOT to commercialize Generation I and immediately procede to Generation II,

which is the certifiable version.  Generation II is based on a Motorola PowerPC MPC-555 processor.  It is at least as powerful as what you find in most PCs. It is also developed in a modern
programming language, with a FAA-certified compiler, on a modular and very flexible architecture that will allow the software to grow and age well.

The Powersport ECU is working on Windows 98 as far as I was told.  I haven't heard that Windows is a FAA-certified operating system!  I do not know what precise safety features Powersport has
implemented but, based on my experience with Microsoft products, I would be reluctant to trust the ignition of my engine on the "crashworthiness"  of Window 98!!!



Our data logging is going to be "smart" to give high resolution data when needed and compress it during constant power cruise.  The idea is to log once a second the data when it changes.  We think
that this resolution is plenty good enough for an aircraft application... it is not Formula 1 data logging after all!  Inversely, if you cruise for 2 hours and a given parameter doesn't change by
more than a given threshold (2°C on EGT for instance), then the unit will store only 1 measurement for the entire 2 hours, yielding dramatic saving in storage capacity.  When you download the data,
a very simple decompressing algorithm will give you all engine parameters with the resolution you want, down to a 1s resolution.  This way you can plot most of your flight with low resolution and
"zoom in" particular events you'd like to analyze.  It's simple to program and very neat to use for the "data freaks" like myself!  J



Have a good trip,  Francois

Yes. That is right about the certification. About ten years ago the FAA balked
on Windows based moving map programs as Microsoft refused to supply the source
code to the OS. There was a lot of controversy about it and one company 
that was attempting to certify their Windows based moving map software went 
bust I think. This is the first I have heard that the FAA came up with some
sort of solution to the problem. Of course I have been out of the loop
for a long time.

I had a discussion with Greg Richter of Blue Mountain and he said he wrote
his own real time non preemptive OS. It looked very DOS like to me. His moving 
map virtual reality software is very impressive as far as screen update speed 
is concerned. What you see on the computer screen is what you should see looking 
out the windshield if the visibility was adequate. Not yet FAA certified to my 
knowledge.

I am very impressed Francois. You put a lot of money, time and effort into this system.
I think you are way ahead of Continental and Lycoming that are just now getting into
electronic fuel injection and ignition. They have a lot of catching up to do.
I saw a so-called factory built "electric" turbo Lycoming at Reno. Here are a few pictures.
Note the Nippon Denso injectors and automotive ignition wires just like a Mazda engine :)

Paul Lamar
 
The Rotary Engine NewsLetter.  Powered by Linux.
ACRE NL web site. http://home.earthlink.net/~rotaryeng/            
Copyright 1998-2004 All world wide rights reserved.