Sunday, November 15, 2020

Probe V8 flight ... of sorts

Today was the first flight of Probe V8 with an actual Airball display. Things worked but were not as reliable as I would like. Some notes:

1. There were short periods of "loss of data" which might be caused by buffering in the OS, or might be genuine signal loss. I found no evidence of signal loss when I tried things earlier so I suspect this is some bursty behavior in the OS. Action item: Characterize data reception interval under real-world conditions.

2. The new probe shape is even less well-calibrated than the previous one! The data is there; it's just not reasonable. The airspeed is way off. Action item: Probe calibration.

In general, this is nothing that can't be ironed out with a little bit of work, and we are that much closer to a "kit" for people to build.




Saturday, October 17, 2020

Simple PyGame program to read probe v8 data

After chatting with my friend John Marzulli, the author of the awesome StratuxHud, I became interested in PyGame and decided to see what it would be like to create a simple program to read data from the new Airball probe using it.

The good thing about the ESP32-based probe is that it is a self-contained air data computer, so if I just telnet to the probe, I get meaningful data (angles of attack and yaw, etc.) rather than a bunch of raw pressures that need to be reduced using magic.

So it's now easy to show "real" data using a program as dead-simple as pyball.

This is the program running, ironically on a Raspberry Pi display unit that is one of the first "displays" I ever made, many years ago! A marriage of the old and the new! :)


Wednesday, October 14, 2020

More about Airball probe v8 charging

Fancy aerospace R&D requires fancy instrumentation. No expenses spared. So you will be delighted to know that the Airball project has acquired a top-of-the-line Eversame USB Digital Power Meter (Amazon's Choice) instrument. Nothing but the best.

With the help of this device, and accounting for milliamps here and there, it seems that our charging circuit is "losing" maybe 20 mA somewhere, but otherwise, the current that gets soaked up by the running system plus the current dumped in to charge the battery more or less equals the 470 mA that we are drawing from USB, which makes sense given that we are a "USB500" device that promises only to draw 500 mA. So all is good on that front.

The next step is -- when I know that I am charging, I can put the ESP32 into a sleep mode to minimize the amount of current I'm drawing for stuff like Wi-Fi transmission. This should hopefully let me charge at a somewhat faster rate. It is probably possible to keep my TCP connections going and transmit battery status only, once a second or something, while in charge mode, but that's fancy. For now, I know I can accomplish what I want to accomplish.

But. There is always a "but", isn't there?

Remember how the circuit has this nice blue LED blinkenlight that blinkens when it's charging? In case you forgot, it's this one:


Ya well, so when the power switch is OFF, the TI BQ24075 chip does NOT charge the battery (weird, but mmkay, whatevs), however it also keeps the "charging" LED ON!

In other words, you plug your probe into USB with the power switch OFF; it tells you it is charging; you go to sleep and come back the next morning; and it has lied to you! It has not been charging the battery.

This is bad. Wrong feedback is strictly worse than no feedback. :P

So a very kind EE friend looked over the data sheet and my design, and confirmed that yes, the data sheet is SUPER misleading. According to their design, this behavior is "allowed". They even give you a sample design with a little "charging" LED just the way I've done it, and it's useless.

So basically I'm going to blow away the "charging" LED and instead use the signaling LED that I have access to from software. I will detect whether or not I'm charging, and based on that, blink the LED appropriately. And also do the sleep thing to save current.

Sunday, October 11, 2020

Airball probe v8 battery charging

To match the battery drain test, I timed a battery charge cycle starting from the completely discharged state. Here is what we have:

You can see that my charger is charging at 270 mA, no more no less. It takes about 12 hours to get to a full charge. Can we do better? Let's think this through --

  1. I am configuring the charger chip (a TI BQ24075) to draw at most 500 mA from the USB input. This is so that I am safely a "USB 500" device and am compatible with most computer USB ports and charger bricks.
  2. I am also configuring the chip to charge the battery at whatever current it can get away with, basically, given whatever the input provides.
  3. I am using a "power" switch connected to the SYSOFF signal on the BQ24075 to control whether the entire system is on or off. When SYSOFF indicates the system should be "off", but the USB input is connected, the BQ24075 powers up the whole system anyway. This means that, any time it is charging, regardless of the value of SYSOFF, the circuitry is operating and drawing the usual 180 mA.
  4. For 500 mA of input, we expect the maximum battery current to be (500 - 180) = 320 mA.
  5. We are getting 270 mA, which is (270 / 320) = 84% of the theoretical maximum.

Based on all this, it seems like the circuit is operating the way I asked it to, and indeed, because of the enormous size of my battery (3700 mAh), and the degree to which I am being "conservative" about the charging, I should not be surprised that it's taking 12 hours to charge.

So how would we "improve" this, today or in the future?

The reason I am "conservative" with the charging is that, as a hobby device, this thing will be connected to people's computers. If it draws too much power, the computer (or cheapy USB hub or whatever) will bump it off USB. This kills the ability to program the thing from the same USB port I'm using for charging, and also makes it hard for people to charge the thing simply by plugging it into their PC because they don't happen to have a power brick laying around at any given moment.

I could create two USB ports -- one for programming and one for charging. The programming port would draw zero current, and the charging port would not do any comms. But then I'd have to explain all this, and mess around.

Another way to think about it is this. I run at -180 mA and charge at +270 mA. Since (180 / 270) = 0.67, what this means is, for 1 hour of operation, you need 40 minutes of charging. Is that great? Is it a "fast charge" monster? Is it a consumer device for the ages? No. But ... does it work? Yes.

My inclination is to leave it as-is and call it a measured success.

Saturday, October 10, 2020

Airball probe v8 battery life

I conducted a battery drain-down test from full charge:


Luckily, the onboard battery charger and power monitor gives me info that I send every 2 seconds over WiFi, so I could just telnet to the probe, grab all data sentences starting with a $B, and plot the results. I went from a full charge (the charger "charging" light went off) to shutdown.

The battery that's installed at the moment is a 3700 mAh 18650-size Li-ion.

It looks like we will have a 1/2-day battery life very very easily, probably without having to spec the super large 37000 mAh batteries. This means you can set it on your airplane, go fly around, and pretty much not worry about having to turn it off while you eat lunch. So this part of the design goal is easily satisfied.

For reference, the steady state current draw seems to be around 180 milliamps.



Wednesday, October 7, 2020

Airball probe v8 mechanical build

This evening, I put together what is very close to an Airball probe v8 kit. The first picture is basically what you'd get in the box, and the steps shown are what you'd do to put it together. The results look like this:



To see the build process, check out this album:

Saturday, September 26, 2020

EAA Webinar: Founder's Innovation Prize Grand Championship Preview

On September 24, the EAA hosted a webinar where a bunch of characters from the Founder's Innovation prize competition got to discuss their progress. My friends are all awesome and the Airball project is proud to be featured among them. The following is a video of the event, and it may require EAA access, but the EAA is also awesome and membership is quite inexpensive, so you owe it to yourself to join.

The slides from the Airball portion of the presentation are available here:

Sensor supply chain and COVID-19 calibration stoppage miseries

We are really close to getting our probes to a "done"-ish stage. Really really bloody close. So close. And yet.

First problem: Calibration is blocked by COVID-19

The first misery we're dealing with, along with everyone else of course, is COVID-19. This has caused all the wind tunnel facilities nearby to close down. And there with it goes any hope of real calibration. Now a good friend (not outing him in case he wishes to remain anon) offered use of his own homebuilt tunnel, but that's far away and would require a lot of setup and preparation, and honestly my day job is overwhelming at the moment. (With a nearby wind tunnel, I can afford to cheese my setup a little bit and, if it does not work, I can always go back the next weekend.) It is possible to imagine complicated devices I could fly on my plane to achieve the effect of a "wind tunnel" -- but that would require even more R&D time.

Second problem: Pressure sensor stock is limited

You will recall that, after much tribulation, we decided to go with 3.3V SMT mount SPI Honeywell TruStability pressure sensors. They are reliable, name brand, and easy to use. But the problem is that the range of pressures in stock is limited. You can get what you want but with terms like, minimum quantity 100 and lead time 7 weeks. Yikes. And this is in turn a problem because my "new" probe design, that eliminates the static probe "stick", tends to amplify the pressures. This is good, right? But this means we need at least one of the sensors to be a wider range. And this is difficult.

Look at this plot of dynamic pressure (q) versus IAS:


For a Cessna 172 and thereabouts, you can figure q < 0.5 psi. For a Cirrus or Mooney, we're getting into the range of q < 1.0 psi, in other words, the dynamic pressure doubles.

In the old probe design, with the static pressure stick, two of the measured pressures are in the range [-q, q], and one of them is in the range [0, q]. So for a Cessna 172, with VNE = 160 kias corresponding to q = 0.57 psi, a +/- 1 psi sensor, which is a very common part, is adequate for everything.

In the new probe design, which "amplifies" the pressures, two of the pressures remain in the range [-q, q] while the third is jacked up to the range [0, 2.3q].  At VNE with a Cessna 172, this would mean [0 psi, 1.3 psi]. So this means that, even for the humble Cessna, a +/- 1 psi sensor is really pushing it. Close but pushing it.

I could go out and order 100 sensors of the appropriate size and wait 7 weeks. That would be between $3,500 and $4,500 of parts, and I would be doing this on a hope and a prayer having done no wind tunnel calibration. That is a bit -- um -- let's say, gutsy?
In making the next round of probes, I have to use the 1 psi sensors that G-d has graciously provided us. There is no getting around that. Until I do a serious calibration, I'm not going out and buying expensive crap.

Right now, I have a probe board sitting on the bench that has three +/- 60 millibar (+/- 0.87 psi) sensors. These were purchased when I was using the "old" probe nose design. Might as well use them and, if they saturate, they saturate. We will at least get some partial data out of them.

Moving forward, depending on how things go with the new probe in flight, I might decide to go back to the old probe with the static "stick", or standardize on +/- 1 psi sensors and hope for the best.

In this case, "hoping for the best" means that, for the pressure sensor reading that is in the range [0, 2.3q], we would saturate at q = (1 psi / 2.3) = 0.43 psi. This corresponds to an indicated airspeed of 138 kias. This is a reasonable compared to the VNE for our tiny little LSA.

Saturday, September 5, 2020

Airball probe v8 update

It's been a while since there's been an Airball.aero blog post! Sorry for this. I've been completely slammed at work, and just putting in tiny bits of work on the project here and there. But we've been making progress!

This is the newest design for the probe, the "v8" mechanical and electronic form factor:


We are trying out the new scheme of having a 5th hole at 90 degrees at the bottom of the probe nose, to avoid having a bulky static probe. If that doesn't work out, we can always return to the old static probe without much change to the sensors (there's one sensor that would need to be swapped out for one of a different range, but that's minor).

This is built around a 1.5" x 3.5" circuit board that integrates an ESP32-WROOM-32U module, a Bosch BMP388 barometer, 3 slots for Honeywell SPI HSC pressure sensors, a battery charger, and a USB interface.



The temperature sensor is a TI TMP102, which is supposed to be on a tiny daughterboard. For now we don't have that and are instead jury-rigging a TMP102 breakout board stuck to the outside of the probe. The result looks like this:


The circuit board has two known bugs; everything else seems to work:
  • Missing a pullup resistor for one of the USB comms signals
  • The pressure sensors are too close together and so the plumbing is very poor
The mechanical parts need some more development to make them suitable for being a "kit", but they are getting there. Check out this album to see the process of assembly.

Link to photo album: Airball probe v8

Stay tuned while we get this working. Note that this signals a departure from the XBee comms we had previously: This one is just plain Wi-Fi. The plan is to have this thing set up a Wi-Fi base station with a unique name, and you can jump on that and telnet to a known host and port and get a stream of data messages. We tried UDP but we were getting a lot of losses; we might try that again.

Saturday, April 11, 2020

Display form factor and electronics investigations

The state of the art for our displays remains Jeremy's new and improved, fully custom, and very compact Airball display. This design has everything we need -- bright screen; real-time clock; enough processing power and memory; the works.

As we have used our system in regular flight, however, we have discovered that the Airball use case does not require frequent manipulation of a control knob. This is not a GPS where you constantly need to pan and zoom and enter waypoints. Aside from initial calibration, there are two functions that are done regularly:
  1. Change screen brightness; and
  2. Change the altimeter setting.
It's perfectly okay to have "up/down" buttons for each of these, rather than a nice ergonomic encoder knob. And with that, it's possible to save some valuable front-panel space.

The culmination of this thinking is the following rough mockup:




Note we have a row of 5 buttons across the top, which take hardly any space at all. The remainder is just barely larger than the LCD display itself. There remains plenty of space on the PCB for our Raspberry Pi Compute Module 3, and any other electronics we might need. And without the knobs adding thickness, we can make the whole assembly very thin.

So -- this may seem like a step "back" in ergonomic goodness, losing the nice chunky aviation-feeling knob, but we feel it's a step forward in general usability in a cramped cockpit.

*  *  *

Now as for the innards, these will have to change somewhat. We are now going to need to use Wi-Fi rather than the XBee modules. The Raspberry Pi Compute Module 3 does not contain on-board Wi-Fi. We have two options, actually, which differ somewhat subtly....

The first option is to add to the board some sort of embedded processor that is Wi-Fi capable and which lets us grab the data we need. For example, we could embed an ESP32-WROOM-32U and have the Raspberry Pi "program" it on the fly using a USB connection, and somehow use it to grab the Airball data. This is completely possible and will definitely work.

But a second, better option is to add a Wi-Fi processor that the Linux distro and device drivers on the Raspberry Pi can recognize as a generic Wi-Fi adapter and use natively. That way the Wi-Fi connection could be better for general purpose use. Including uses that we might not ever have thought of -- I mean, if other folks can use this display for their own projects, for whatever reason, this just adds to our own economy of scale and makes the world a better place. Right?

So this second direction has us looking at stuff like a TI WiLink adapter connected to the Raspberry Pi Compute Module 3 via its SDIO interface. If we can get that working, it would be far preferable. The one problem with the TI WiLink modules is that they do not have an on-board u.FL connector for the RF -- they break that out as a pad on the module, and you must build your own antenna. I think that this still means we can consider our system to be "pre-certified", and it's not rocket surgery to create a tiny trace leading to a u.FL connector on the board we design ... but it's something we need to think carefully about.

*  *  *

While on the topic of display electronics, we thought somewhat about whether we should try to go with a BeagleBoard Black base rather than our current Raspberry Pi. The BBB has many advantages. For one thing, it breaks out "raw" LCD panel outputs from the board itself, whereas the Raspberry Pi (even the Compute Module 3) produce HDMI outputs, and we need an HDMI decoder to turn that into raw LCD signals. Also, at some point, we can simply embed the Octavo OSD335x System-in-Package in our system, which would contain pretty much everything we need and would be super compact!

We did some early comparisons of the performance of a BBB and a Raspberry Pi 3+.

This is a video of the BBB showing about 14 frames per second drawing Airball in an X11 environment. For comparison, this is a video of a Raspberry Pi 3+ showing about 23 frames per second on the same task. So the Pi gets about 164% of the performance of the BBB given these constraints. That's one data point.

We tried to run our Airball software with the Linux framebuffer on our BBB, but it locked up. We were not able to get it to run at all. We had that trouble a couple years ago, and things have apparently not changed. We are not doing anything "weird" in our software, so strike one against the BBB, from a viewpoint of just amorphous technical risk if nothing else.

Finally, we ran our Raspberry Pi 3+ with the framebuffer, with an 800x600 screen. Note that this will be slow than our regular 480x272 display, because even if we are not painting the whole 800x600 buffer, we still have to ship it in an out of display memory. But that was the test setup we had, in any case, and this is a video of it running at 16.5 frames per second.

Now recall that we are sending data from our probe at 20 Hz, and we really don't want to go below 20 frames per second so as to maintain the illusion of a smooth "analog" instrument. We therefore conclude that:
  1. We are not confident that the BBB / Octavo 335x will give us adequate performance;
  2. As best we can tell, we are probably pushing the display performance with our application anyway, so we can't afford to slack off;
  3. The BBB / Octavo 335x has shown nontrivial technical risk due to framebuffer crashes;
  4. The Raspberry Pi is updated constantly with new models, whereas the BBB has stagnated somewhat;
  5. The Raspberry Pi is more popular in the usual hobby circles, and in particular in aviation hacking (note the "Stratux" ADS/B receiver, for example); but mainly
  6. We already have a super performant and super compact Raspberry Pi Compute Module 3 design that Jeremy created, and any modifications we need to make to it are minor.
Our decision therefore is to continue to pursue the Raspberry Pi Compute Module 3 design. Maybe there will be a time when we need a super lightweight, super small Airball display, and we can revisit the possibility of using some other processor. But for now, we believe we have done our due diligence and should proceed as previous with the excellent design that Jeremy created.

*  *  *

One of the thoughts we have is, what about other output modalities? Folks are working on giving air data information to the pilot using haptics, sound, and any of a number of other things we haven't even thought of yet. Can we support these use cases? If so, then how?

The easiest way we can do that is to provide a series of GPIO pinouts in our new display board, arranged so that they can be populated with 0.1" screw terminal blocks or any other kind of connection that someone might like to think of. It's not yet 100% clear where or how, but basically, if there is a convenient I/O from the Raspberry Pi Compute Module 3, and we are not already using it, we should consider making it accessible as a simple pinout.

Probe mechanical form factor investigations

Recall from our posting Ideas for a next-generation probe that we were thinking of going to a 1-inch diameter tube for our new probe, since the new ESP32 hardware is compact enough to let us get away with it. We have done a lot of thinking about this, and we'll share some of it.

We have been sheltering in place from COVID-19, and so our planned test flight schedule has been severely curtailed. This kind of work -- thinking and prototyping at home -- is still possible, though.

The quick summary is that this geometry imposes some difficult constraints that would be just fine if we were building some production device in a factory, but may conflict with our goal of making a probe design that anyone can easily reproduce from first principles in their home workshop. And so, this being still early in our development of Airball, we have rejected it in favor of our 2-inch diameter geometry. But we have some cool ideas for that, which you might find exciting. So read on.

It is important to understand our design constraints. We can build "anything" if we assume we have a factory producing stuff in volume, with injection molding and custom metal stampings and what not. But we don't. Our self-imposed constraints are:
  1. Our design can be built from scratch using a commodity 3D printer and readily available parts. The builder will need to order a 2-layer PCB, perhaps with a paste stencil, and do a surface-mount assembly of the components.
  2. Our design can be built from a kit by a hobbyist using screwdrivers, small wrenches, pliers, a commodity electric drill, sandpaper, and possibly CA glue ("Super glue"). The kit builder must not be required to do any soldering.
  3. Our kit can be constructed via a farm of commodity 3D printers, and PCBs ordered pre-stuffed from a small volume assembly shop, with possible lightweight post-production operations like soldering on headers, connectors, or large-tolerance surface-mounted parts.

*  *  *

Recall that our new 1-inch probe started out with this idea:

This is all well and fine, but it required electronics in front of the battery (the sensors connected to the front nose) as well as electronics behind the battery (the connections for USB and the on/off switch, and perhaps also the temperature probe). How to hook all that up was up in the air.

Building ad hoc soldered wires between components like jacks and switches is always hard. And wires fatigue where they are joined to things, and eventually break. So really, we were talking about having two designs, which we will discuss in sequence. The first is to have two circuit boards, one in front of the battery and one behind it, connected via something like an FPC cable. (Standard ribbon connectors are way too bulky.)

This is the state of the art of where that design ended up. Note the 3D printed supports for the forward and rear circuit boards. Note how the battery is suspended inside the tube, and there is room for an FPC inter-board cable to slip into a slot beside it. Note also the fact that the rear board projects out of the housing and carries at its tip a tiny temperature sensor chip (e.g. a TI TMP102) so that we an do away with all random wiring. The rear board also contains the on/off switch and the USB connection. The printed circuit board can be single-sided from the factory to save money; the pressure sensors are easy to solder onto the second side and can be done as a separate step.



We fabricated some parts of this design and put them together briefly, and the parts looked like this:



Mechanically, everything worked out fine. There were two problems, though.

The first was the inter-board connection. We spent a bunch of time looking at FPC cables and connectors, and thinking through how this might actually work out. It's a bit of a finicky business, but it is not insurmountable. The number of connections to the rear board would actually be nontrivial; we would need:
  • Power: GND, USB VIN
  • USB data: D+, D-
  • Power switch: A, B
  • Temperature sensor I2C: SDA, SCL
This is 8 signals, meaning we'd end up with a 10-conductor FPC cable. It would all fit, but it would be finicky and customized. We could not see an easy way that the front or rear board could be "re-used" in a different design; at least not without some crazy hackery. So anyway.

The next thought was to try to consolidate the boards, and instead of sneaking electric signals past the battery, to instead sneek pneumatic connections past it. This caused us to investigate a whole family of designs that looked somewhat like this:




In these, the battery is pushed off to one side of the tube to make room for the six plastic hoses needed to get the six independent pressure signals to the (now, unitary) PCB on the back. We prototyped this, and it looked something like this:


 


Using 1/8" diameter plastic tubes, the fit was very tight. Not impossible, mind you, but tight. As a solution, we could go to a smaller tube, e.g., this 3/32" diameter Tygon tubing.

We investigated using the 3D printed parts themselves as conduits for the pressures, by building long channels into them:


In the end, the conclusion is that this is all possible, but it requires a bunch of engineering and testing to get it to work right. It is definitely an optimization.

Now as to the electrical connections to the battery. Clearly we cannot fit a simple 18650 battery holder into the tube. We must solder to the battery, or devise some sort of spring-loaded contact of our own. Soldering wires directly to the battery is possible, but it invites fatigue at the solder joints. 18650 batteries come with solder tabs, but we'd have to figure out how to finagle these into our overall design with the appropriate clearances. We'd also need to make sure we are not relying on a single boutique design of 18650 battery with tabs that are just so, and which could kill our design if it were discontinued.

Based on all of this, we decided (and it's a difficult decision, believe me!) to set aside our 1 inch diameter probe ambitions for the time being. This does not mean never. But our first kits will be built around our 2 inch "caliber".

*  *  *

To that end, we've returned to thinking about how we'd make things work. This is a very early snapshot of our arrangement:


Now we have lots of room for a standard 18650 battery carrier on one side of the board, and plenty of room for getting tubes to the sensors on the other side. This looks much more like a design that anyone can put together easily, without being too error-prone, and which is more likely to succeed at its mission rather than try to achieve premature optimality.

In this design, the circuit board length is bounded by the length of the battery and its carrier, which means the circuit board is 3.5 inches long. We end up with something still much more compact than what our earlier prototypes.

Again note how we have extended a little proboscis from our main PCB to carry our temperature sensor. We may or may not continue this trend. The thing is, with more space on the PCB, and more room in the probe overall, we can afford to have more "generic" connection options for I2C or 1Wire temperature sensors. We may even be able to use a standard Sparkfun TMP102 Breakout as our temperature sensor daughterboard, building strain relief and housings for it as appropriate in the 3D printed parts. Simple and easy is better than complex and hard at the moment.

*  *  *

With the decision to go with a 2 inch "caliber" probe, we now have a stubbier probe. This means that our bulky snap-off mounting that we've been using is going to be very close to the probe nose, and might disturb the airflow. Without doing wind-tunnel testing, we know that less disturbance is better than more. So if we can get our mounting behind the probe, away from the nose, this is likely to make things better, or at worst be neutral.

Our basic requirement from our mounting is what firearms people call a "return to zero" mount -- when put back together, it should maintain its original direction. It can move forwards and backwards along that direction a little bit, but the direction is what's important. This led us to think of some sort of Picatinny rail along with a quick release Pic rail mount. There are even plans for a 3D printed Pic rail quick release out there! We thought about building a back cover for the probe that incorporates a Pic rail shape:


Ultimately, though, this all seemed like lots of work. The sweet spot would be for the Pic rail to be mounted on top of the probe tube, but we already decided we don't want that because it interferes with the airflow. So we decided to set aside the Pic rail options for a while, regardless of how nice it would have been to somehow unify the aviation and firearms universes for a brief moment.

Our current best guess is screws on the back, and a slotted back plate that carries a RAM mount ball:






A screw with a 3D printed thumb knob goes into the bottom hole to secure and tighten up the arrangement.

This basically precludes sticking things like a temperature sensor "proboscis" out the back of the probe. This is okay. Our current idea is that we will embed our temperature sensor stuff, whatever that is, into some 3D printed parts that form part of the probe nose. It should be easy to make the nose half an inch longer and make a "pocket" of some sort within it so that air can circulate around a temperature sensor, yet not interrupt the outside radius of the probe as a whole. With the new-found flexibility in space that the 2 inch "caliber" gives us, we believe we can make this happen.

*  *  *

In the process of redesigning the nose, we are again looking into "design for kit-ability". Our current direction is to move away from extremely complicated 3D printed holes in the nose, and towards holes that have fewer kinks and can therefore easily be cleared of debris by a hobbyist using a pin or wire or some other simple manner. This means that we may be going to a "stacked manifold" design as we reported in our blog post from 2 years ago, Probe nose progress. The advantage of these kinds of designs is that they can also easily be machined or injection molded -- they do not rely for their feasibility on the ability to 3D print "impossible to machine" shapes.

Stay tuned for more progress on our designs!

Saturday, March 28, 2020

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.

Sunday, March 22, 2020

ESP32 probe code complete

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

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!

Sunday, March 15, 2020

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!

Saturday, March 7, 2020

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!