More probe testing

The probe testing with the "kite" proved somewhat disappointing, I'm afraid. The problem is that the airflow near the hood of the car is curved, so the tail feathers of the "kite" fly in one direction, while its nose is pointed in another direction. I did some testing and verified the angle difference was on the order of 5 degrees nose-down. There may be ways to fix this, and the "kite" does give us good natural stability, but for now I decided to set it aside.

So now we just have the probe mounted on the PVC pipe proboscis using two servo motors. Here it is looking a tiny bit sad and droopy:

It turns out the 12VDC in the car is actually a little over 14V, which over-volts the Dynamixel servos. I decided to instead use a 3S LiPo from my RC airplane days. The long wire to the Dynamixel servos caused intermittent data errors -- I'm suspecting I need to use a twisted pair, since I recall the protocol is basically RS-485 plus power. But no matters. I am getting data. Here's what's on my lap while Melissa drives the car:

My plan is to run a "find zero" routine to zero out the probe, then do a series of sweeps at various speeds with cruise control on. I got a tiny bit of data and it looks reasonable but noisy. I will do some more programming to make my data acquisition stuff resilient in the face of comms failures, and then go out for some more test runs when the roads are quiet. Stay tuned.

For now, this is what the probe looks like when it's "flying":

First highway run with probe

 Whelp. I made a non-moving (for now -- no alpha/beta servos) mount for the probe onto the "kite" and it seems to hold together. I got the location of one screw wrong so I had to use some duct tape:

The result of my quick W&B is that it ended up a tiny bit nose heavy, but not by much. That's fine for now. I ran it for the first time on the freeway, up to about 65 mph, in heavy turbulence so I did not push it any further. But overall, it looks stable and, on a quiet morning on an empty street, I expect I could actually get data out of this thing. Here's the video:

Probe road testing proceeds

 We're back to putting whacky stuff on the Prius! This time our pole is a PVC pipe facing forwards:

The "kite" is not yet mass balanced, so we took it on quiet streets in the neighborhood, going up to maybe 45 mph. It was stable up to that point, and we did not push it. Here is a video of  the "flight":

The "kite" gets "on the wing" at about 13 mph, and with a bit of creative steering, it's possible to free it from the ropes if it gets stuck on them. Otherwise, it seems reasonably trouble-free.

Subsequently, I did a quick balance test to measure the rearward moment of the weight of the thing, and am now 3D printing some more stuff to move the payload mass forward to counteract the tails and make it mass-balanced. Stay tuned.

Raspberry Pi Compute Module 4

 While we were snoozing, the Raspberry Pi Foundation released the Compute Module 4. This is a serious upgrade from the previous Compute Module. The main thing it provides to us is an option for on-board Wi-Fi with a u.FL connector for an antenna. This means that we don't need to design our wireless solution any more; it's done for us!

With that in mind, and given that we are using Wi-Fi not XBee for wireless, it is now possible to design a simpler version of the awesome display board that Jeremy built! For the new version, I'm looking at a serious downgrade, in favor of simplicity, for some important items. Yes, sometimes less is more.

First, I'm dropping the adjustment knobs and just using a row of clicky buttons. Yes it is just like the cheapy monitor controls on your cheapy monitor. But it also saves valuable space. Anything that helps us fit into a crowded instrument panel on an airplane is a net win.

The previous design also had a very clever microcontroller to make sure the brightness adjustment worked even when the Pi was booting up. In the new one I'm just hooking up a Pi GPIO to the brightness PWM input, and calling it a day. I might add an inverter so it's at full brightness until the Pi boots up, but yes, it will be in an indeterminate state during bootup, and hopefully we boot up quickly so this is not an issue, but for now, this just makes things simpler.

I added space for a real-time clock and a battery for it, but I'm not sure if I will populate it. We'll see. Having actual time is useful for data logging, but honestly, it's just as easy to use a sequence number or whatever and be done with it.

The CM4 has a power supply built in now, so we can lose all our power circuitry. We just get 5V input from USB or wherever, and we're good.

I've arranged for two USB-C power socket for either vertical or horizontal mounting. The USB-A socket is there for attaching peripherals, a keyboard, or anything else. If you want more than one port, use a hub. :)

Finally, I'm explicitly adding slots for two 8-position 0.1" screw terminals to allow expandability and support wired use. This all fits in with the idea that this is supposed to be a general purpose, expandable, in-vehicle display unit for all kinds of use cases.

The result is something that should be super small -- see this previous blog post where I made a mockup. This is the current state of the circuit, which is still in development. It's funny that, for all its fancy functionality, it's actually somewhat simpler than the sensor board!

Thinking about road testing probes

I have a new version of the probe PCB out for production at the moment, and I think this might be good enough for being the core of a "kit", so now we move on to other things....

Calibration of the probe is of course a huge issue. I've been trying to get wind tunnel time -- and I have a generous offer from a friend, but he lives rather far away. So I've been trying out various ideas on the side.

Remember the road tests of the probe? Well so I took out the probe on the road, mounted on a pole in front of my Prius, and tried smoothing the data, and it looks like I could get a reasonable reading if I average for, say, 1 second or so per reading. This might be enough for a "useable" calibration, while I wait for a real wind-tunnel run.

The problem of course is how to establish a "zero" for the wind direction. At the moment I don't know, but I've been thinking of making a "kite" mounted on a universal joint:

This is an articulating head boom, with the 3-sided fin geometry inspired by Andrew Angelotti's Model 23 probe. The parts are 3D printed, with 3 carbon arrow shafts and balsa fins. The fin supports have little compartments for mass balance, if needed (unlikely -- I expect this to balance tail heavy unless nose weighted):

On the end, I show a Robotis 2XL430-W250-T servo (2 axes in one, and one of the cheapest you can get that has the more accurate contactless magnetic encoders) with a pair of FR12-H101K hinge frames.

The idea is that, if the vanes of the "kite" are large enough, then the mis-alignment caused by the asymmetry of moving the probe side to side does not move the "kite" very much. This in turn means that I can rely on the inaccuracy of the relative wind being somewhat bounded.

The alternative is to mount the servo base rigidly, and try to "calibrate" it for the specifics of the car somehow. That seems error-prone and more difficult to set up, but easier to build.

As a final though: The action of the passive vanes to center the "kite" into the wind can be thought of as a form of PD (proportional + derivative) control -- there is a correcting factor proportional to the error, plus some damping. What is missing is the "I" in PID control -- an integral term. This is what would drive the long-term error to zero. And the way to do that would be to:

1. Measure the wind direction relative to the probe base; and
2. Use a second set of servos to redirect it into the wind.

The measurement need not be accurate -- it just has to read "zero" when the probe is directly into the wind. Typically you can do this with another air data probe, and just drive the left/right and up/down delta-P values to zero. And this is basically a nulling probe. But that's adding an actual feedback loop and a second servomechanism....

I don't know what I'm going to do yet. For now I'm just tooling around with this. Stay tuned!

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.

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! :)

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.

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.

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.

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:

Airball probe build 2020-10-07

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.

https://eaa.org/Videos/Webinars/Products/6194321891001

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

https://bit.ly/348evJo

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.

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.

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!