http://www.haltech.com/



 Source: 8.6 to 16.5 Volts DC
 Consumption: 530mA @ 12Volts DC

 Physical Dimensions:
 ECU Dimensions Length: 154mm (174mm 6.85" with MAP nipple)

 Width: 158mm 6.22" Height: 42mm1.65" Weight: 680g 1.5 pound.

 Price: $1,587.00
 Includes Free Ground Shipping!


 Bruce

 Yes I have heard of them as well as a half dozen others.

 They don't give you what you want to know on the instrument
 panel. They are also way more money than the PC solution.
 The PC can store 64 Gig on just one USB stick. Not just 500K.
 It can also log data every second.

 Closed loop O2 control does not work with 100LL aviation
 fuel. The lead contaminates the O2 sensor.

 The fact of the matter is the modern $80 PC Intel Atom mother board is
 ten times as powerful as the processor your likely to find in these
 automotive ECU's. When you add the $90 Hytek you have a total of 3
 processors all working together.

 ----------------------------------------------------------------

 Here is the specs for the 2 rotor version.

 Paul Lamar


 Hi Paul!

 Thanks for your hard work in this forum.

 You are heading the right direction with the PC solution.

 I was once close friends with Jim Munn, the owner of MOTEC USA in
 Huntington Beach CA. He provided the ECU to Mazda for the Le Mans
 winning 4 rotor car back in the early ninetys. (For marketing
 reasons, the manufacturers did not allow MOTEC to put their name on
 the race cars).
 I am writing to address all those who keep bringing up these race
 car ecu units unnecessarily. Aircraft simply do not need what the
 MOTEC, or any of the other highly capable units for race/street
 performance cars can do. Even the lowly home built Mega Squirt is
 more than is needed. (I own two of those)
 Think about this folks, what Paul is doing with the PC solution is
 far superior to any of the automotive units. He will potentially be
 providing users with capability to interface all of the functions of
 the aircraft, directly on the instrument panel, not just the engine,
 or monitoring flap angle, airspeed, etc. But we would be able to use
 it to control everything, even flying the plane remotely, or with
 auto pilot operated from the PC board; just on one of these small
 fast PC board setups.
 Imagine getting into your craft, turning on the ignition, and
 looking at a 15" computer monitor that you built into your dash, and
 seeing hundreds of data streams on display, access to pinhole mini
 cameras mounted in you cowling, or anywhere else!

 This is transformative, it is revolutionary to the experimental
 home built industry. I truly hope some of you programmers join in
 with Paul to make it a reality.

 Ed Carver


 Racing Beat sells and supports the Motec unit and it is a very good
 unit.
 Price however is about $1,800.

 Thanks Ed for your understanding on this issue. I might also point out
 that there are some very sophisticated moving map programs out there
 that will run on the same type of PC mother board and hardware. Some
 show the terrain you are flying over in 3dwith all obstructions
 shown so this is a monumental advantage in low visibility conditions.

 http://www.navzilla.com/

 I wrote my first articles for Kitplanes on this subject back in 1988
 1989.

 The Home Built Glass Cockpit by Paul Lamar
 Kitplanes
 June 1988 page 69
 The future can be here now: electronic
 instrument displays in your homebuilt.

 Glass Cockpit: Part II by Paul Lamar
 Kitplanes
 January 1989 page 66
 Automatic position reporting could be helpful
 when pilot's hands and mind are full.

 Paul Lamar



  HEY PAUL!!!!!!

  I just felt saying THANKS A LOT FOR LETTING THE REST OF
  TAG ALONG FOR A GREAT RIDE!!!!!![YOU'RE THE MAN!]

  Gene Kahn


  Here are some pictures of my late 1980's glass cockpit in the C182
  with a 8088 mother board. Updated the map every second written
  in QB under DOS no less. I would use QB again and DOS if it
  supported USB but it won't so Linux and C it is.


  Paul Lamar

 Paul,

 This is good information to know. This was why I was asking what the main
 objective was so I didn't go over the same material that you had already
 explored and ruled in or out. That is not helpful to you so let me say
 this,
 if you have an area or an item or a piece or part you need help on to
 search
 for, I will be happy to help you. I have a better picture now of what I
 think you are trying to achieve however I don't know what you already have
 or where you are. In other words, say you have a monitor and a keyboard but
 you want an integrated touch screen or look at several to make a choice of,
 give me some idea of your specs and I can search them out and provide you
 with as many as I can find to chose from. As it is, it's not helpful to
 you,
 to have people throw stuff at you when you've already passed that stage of
 development. Also maybe you already have research people who are helping
 you
 on specific things and you don't need anymore input that's fine too. I have
 plenty of my own proprietary projects that I work on so there are no hard
 feelings.

 I do want to commend you for doing this and wouldn't it be nice to have
 full
 control and visibility (transparency as it's now called in politics) of our
 autos and not get just an idiot light for all the bucks we pay for a car
 let
 alone a plane.I mean we should at least have a switch for "idiot" or "full
 view" for those of us who want to look in and see all the registers we can.
 We can then switch it back to "idiot" or "MIL light" and go back to sleep
 at
 the wheel on those long trips on I-15. The Auto Cartels act as though we
 are
 going to steal something if we know what we are actually dealing with when
 we take our cars into the shop. As it is we are blind victims.

 I like following your posts though. If you have a story about your research
 and where you've come from and where you're going to, it would be
 interesting. I like the story about your 182 with the 8088 with QB and DOS.
 Back when a dual 360kb floppy or a 10mb HD was tall cotton. You were far
 ahead of your time even back then.

 Bruce

 What I need is some C programmers. The hard ware is pretty much
 cast in concrete.

 Paul Lamar
 --
 The Rotary Engine NewsLetter. Powered by Linux.
 ACRE NL web site. http://www.rotaryeng.net
 Youtube key word PaulLamar2
 Copyright 1998-2009 All world wide rights reserved.



Paul,

Send a conceptual dwg or whatever you have and I will take a look to see how
much time we are taking about.

bruce


I like to use hardware interrupts for real time stuff.

http://tldp.org/LDP/lkmpg/2.4/html/x1210.html

"Interrupt Handlers

Except for the last chapter, everything we did in the kernel so far we've done as a response to a process asking for it, either by dealing with a special file, sending an ioctl(), or issuing a system call. But the job of the kernel isn't just to respond to process requests. Another job, which is every bit as important, is to speak to the hardware connected to the machine.

There are two types of interaction between the CPU and the rest of the computer's hardware. The first type is when the CPU gives orders to the hardware, the other is when the hardware needs to tell the CPU something. The second, called interrupts, is much harder to implement because it has to be dealt with when convenient for the hardware, not the CPU. Hardware devices typically have a very small amount of RAM, and if you don't read their information when available, it is lost.

Under Linux, hardware interrupts are called IRQ's (Interrupt Requests)[1]. There are two types of IRQ's, short and long. A short IRQ is one which is expected to take a very short period of time, during which the rest of the machine will be blocked and no other interrupts will be handled. A long IRQ is one which can take longer, and during which other interrupts may occur (but not interrupts from the same device). If at all possible, it's better to declare an interrupt handler to be long.

When the CPU receives an interrupt, it stops whatever it's doing (unless it's processing a more important interrupt, in which case it will deal with this one only when the more important one is done), saves certain parameters on the stack and calls the interrupt handler. This means that certain things are not allowed in the interrupt handler itself, because the system is in an unknown state. The solution to this problem is for the interrupt handler to do what needs to be done immediately, usually read something from the hardware or send something to the hardware, and then schedule the handling of the new information at a later time (this is called the "bottom half") and return. The kernel is then guaranteed to call the bottom half as soon as possible -- and when it does, everything allowed in kernel modules will be allowed."

I'll do a flow chart shortly.
In the mean time read this.


Paul Lamar