Sunday, August 4, 2019

Once more unto the breach, yet fear the failwhale

Armed with the hypothesis that my failure of yesterday was due to heat, I took flight this morn in my trusty steed N291DR with my trusty equipment, for to secure data:




Yet alack, 'twas not to be. The data recording cut off during or soon after takeoff, again. And when I unplugged the probe and plugged it back in again just after landing, it worked, so it's not the heat; it's probably the vibrations. And in fact, here is a trace from one of the pressure sensors:


This sad song has been sung before. It's I2C bus flakiness caused by bad wiring somewhere. And indeed, as we know all too well, it locks up boards.

It is generally true that I have never had any luck flying kludgeboards. There is something about the flight environment that just kills connections, no matter how carefully done. Unless something is truly rock freaking solid, there will be some intermittent thing somewhere, and you'll find it as soon as you take off. And note that the bar for a "kludgeboard" here is not excessively high. The stuff I was trying to fly is basic hobby breadboarded electronics stuff.

I'm not sure what has been going flakey, but it may be a bad solder joint, or it might be that the 0.1" header connectors are for some reason not as secure as I'd like to believe they are.

So what's to do? Well ok, let's review the three issues we wanted to test by flying this experiment, and discuss whether we can back off in some interesting way.

1) What is the difference between the static probe "stick" and the 3D printed probe nose holes? This relates to the mechanical design of the probe and we can iterate on that separately as we need to. All we need is some pressure measuring board (we have plenty) and a test rig, and we need to measure a couple of pressures (including the difference between "static" pressure as measured by each of the different static source geometries). This can be done as a standalone experiment and need not block anything.

2) How does the aero derived beta signal differ from lateral acceleration? Adding an accelerometer to our board is cheap, and we need to rev our board anyway, so why don't we just add the accelerometer and call it a day? Later we can decide on the relative accuracy of each source, and anyway, we're planning to make the choice of lateral position (ay/Q or aero derived β) a user choice in the UI, so why worry?

3) How do the Honeywell sensors perform in a probe? We know others have used the Honeywell sensors and they work fine. Let's just rev up a board using them, and take the hit. It will cost less time, and perhaps even less money, than MacGyvering up a bunch of "test" boards and wasting time.

No comments :

Post a Comment