ESP32 probe ongoing programming

After some digging around, I decided to change the ESP32 probe's protocol to TCP rather than UDP, at least for this initial stage, to ensure that we got a reliable stream of messages, and any unreliability would be more correlated with something in the probe itself. As usual, check out our code in the airball_probe_es32 directory in our repo.

The innards of the probe are now on a piece of plywood, and they look like the below. Given that what you see is all we need, this should all be quite easy to integrate into the 1-inch diameter new probe form factor.

The Wi-Fi RF performance seems excellent. I put this stuff all the way across my yard and behind the house, covered with a large metal garden dustpan, and I still got really good quality reception from my computer's Wi-Fi. That's very encouraging.

In other good news, if the battery monitor is to be believed, we draw about 170 mA when operating normally. With a 3400 mAH battery, that's about 20 hours of life. If we de-rate this to protect the battery, we still can expect a safe 12 hour battery life, which is my metric for, basically, "all day long". This means that a pilot or CFI can plop the probe onto their plane in the morning, fly around without paying any attention to it, and pull it out and put it on the charger in the evening.

Less encouraging is that, for some reason, I now seem to be having power supply issues, which cause flakey performance of the sensors and the Wi-Fi. Now it worked previously just fine, so I assume my wiring is crappy or I need decoupling caps, or some combination. But in any case, before we call the circuit done, I need to make sure these gremlins are no longer there, and learn what mitigations, if any, I need.

ESP32 probe code complete

Yesterday, I got the ESP32 version of the probe up and running with the following setup:

• Microcontroller: Espressif ESP32-DevKitC
• Pressure sensors: Honeywell HSCMRRN060MDSA3
• Thermometer: Sparkfun TMP102 breakout
• Barometer: Adafruit BMP388 breakout
• Battery charger: Sparkfun Battery Babysitter
• Battery: Panasonic NCR18650B 3400 mAh

The code is in the firmware/airball_probe_esp32/ directory of our repo. This verifies that we can connect to our SPI and I2C sensors and get battery statistics over I2C, and broadcast the results by establishing a WiFi base station and broadcasting UDP packets on a well-known port.

The ESP32-DevKitC bundles a lot of the USB and power regulation machinery together, and uses an obsolete USB part, so I am hoping to bench-test a more stripped-down setup before spinning up a custom PCB. To that end, I need access to the individual pinouts of a raw ESP32-WROOM-32U module, and so this is what I made:

I will be reporting more on the following --

1. Verifying data rates and reliability with the UDP transport.
2. Battery charge time and battery life with the new battery.
3. Results of trying out the more stripped-down ESP32 setup.

If this all checks out, then we are well on our way to a really compact, and relatively low-cost, version of our probe electronics. Stay tuned!

Calibration curves in the ESP32

Given that I'm planning a transition to the ESP32-WROOM-32U, I'm going to have way more memory to play with than I had before. That means I can embed calibration surfaces (see the last blog post...) directly into the probe, without having to come up with a fancy curve-fit to save memory!

This weekend, holed up in the house due to COVID-19 and grounded due to rainy and cloudy weather, I have been doing just that. The results (ongoing) live in the airball-probe-esp32 directory of our Github repo. Just one function call that does 3 table interpolations is enough to turn the three pressures, (dp0, dpa, dpb), into the three airdata parameters, (α, β, q).

The calibration tables are currently generated based on potential flow formulae, in Python. Of course a future, and better, implementation would be to derive these from wind-tunnel data. But the beauty of this is that we will have verified the entire stack, execution speed, memory usage, etc., and will just swap in some numbers in place of others.

Stay tuned for some hardware prototyping with the ESP32-WROOM-32U next!

Quick flow math for new probe nose

Per my previous post, I have been thinking about getting rid of the static pressure tube just using an extra hole in the front "ball" nose. The following is some simple back-of-the-envelope math to see if that is likely to work.

First let's describe our setting. We plan to add a 6th hole 90 degrees from the centerline, at the bottom of the probe, as follows:

You can see that we measure pressures dpα and dpβ as usual, but dp0 is now between the center hole and our new 6th hole in the 90-degree position.

Using the standard potential flow formula for a sphere, we came up with the expected pressure ratios, to see if we are likely to get good data or if we'll have nasty singularities. The good news is that all seems promising.

We will plot various values for a range of α and β of ± 25 degrees. The color in the following plots is a measure of total angular distance from the centerline, to help with visualizing the surfaces.

First, let us plot the actual pressure differences measured by the sensors, in relation to the free stream dynamic pressure q. We plot (dp0 / q), (dpα / q) and (dpβ / q):

The ratios are all reasonable and there are no surprises. (dp0 / q) is around [1.0, 2.5], and (dpα / q) and (dpβ / q) are both in the range [-1.5, 1.5]. In particular, (dp0 / q) is a reasonably solid value and will not be close to a divide-by-zero

Now we plot our pressure ratios that we will use to calculate α and β, (dpα / dp0) and (dpβ / dp0), to see if there is a clear signal:

The range in both cases is about [-1.5, 1.5] and approximately linear. That is very good.

We conclude that this probe nose design is well worth pursuing. The pesky static pressure rod is a pain in the neck to mount, and it makes our probes a lot more bulky. It would be awesome to get rid of it!