Thanks @Lenny for the detailed reply.

I get the I2C limitation, especially with 3 of the same unit with non-programmable address. Using the controller chipset directly on a custom board rather than via a development board makes that less of a problem as the ESP32 can handle multiple I2C busses. There are also SPI versions of the pressure sensors available so they could go on a single SPI bus.

I'm deleting the GPS idea and will implement the pressure sensors as you have them.

I'm putting an audio codec on the board for the audio out via I2S. It's not expensive and can handle 16bit stereo and has "pop reduction"; libraries may be interesting - that teensy Audio library is really nice and I may try to port some of it!

This may take a while! I'll let you know how I get on.

Cheers,

Gareth.

Teensy 4.1 is in stock https://www.pjrc.com/store/teensy41.html

Is this compatible ?

Max

Gareth,

Yes, the ESP32 is a great idea (we're leaning towards that in our production version), but there are a few challenges. It only has one 8 bit DAC, so no stereo audio, and crappy mono. The 3D audio is awesome, especially in a tailwheel airplane.

Also has a single I2C port, and the pressure sensors all use the same address. This may be different with the Honeywell sensors, not sure.

I've tweaked the tones on the oscilloscope for a while to clean up the audio and take care of all the little glitches when transitioning between the different tone frequencies. The ESP32 doesn't have the same audio library, so that needs to be re-developed.

GPS is too slow for calibration purposes, we don't need or use one.

AOA becomes weight dependent if you use differential pressures for your coefficient of pressure. You can normalize with q (Pfwd-PStatic), most AOA systems do) but you now rely on the static ports which on most airplanes are out of whack, and also misread in a slip/skid. There's an FAA paper out there comparing a bunch of different unnamed AOA systems on the market. The ones that don't normalize properly are weight dependent and worse than useless.

You don't need a display, however I find that it's very useful to have one for a crosscheck.

You can use Efis data instead of using the internal IMU, but our goal is to have this system work in any steam gauge airplane and also provide a backup attitude and air data.

We do use the IMU for acceleration data (G limit warnings), 3D audio (lateral acceleration), gyro rates are also used by the calibration wizard.

There are a lot of considerations that went into this system to make sure the math & physics are correct, not to mention hundreds of hours of test flying with multiple airplanes, a lot of it using a flight test boom and a tactical grade IMU (VN-300). So if you change your sensor setup I suspect you'll be in for a lot of learning :) We have lots of data we can share if you are interested.

Our Gen2 v1 box was a much simpler system. Teensy only, no wifi, RS232 chip for reading the Efis stream, single audio channel, two differential pressure sensors, no baro. I may even have some of those boards if you want to build one. Attached the schematics.

Can the Gen 2 work with out the Teensy Spark fun DEV-14058 ??

It is the only component that I don't have.

Max

Hi Gareth,

I'll leave 1 and 2 for the engineers; but as for your third question/point, the real purpose of the IMU is to enable automatic calibration. If your airplane has an EFIS, then that input would suffice as you are correct that the IMU (currently) doesn't contribute to the AOA solution. Lenny has talked about running the code on the WiFi chip, so that also sounds plausible. It would be an interesting drill.

Cheers,

Vac