Yesterday I made a small contraption to put the Airball display in the panel of N291DR, with a hole for a USB wire and a RAM EZY-Mount:
As you can see, the location of the display allowed me to compare the inclinometer and the Airball airdata-derived yaw quite easily.
The probe was mounted as usual, using our 3D printed mounts on the strut, extending near the leading edge. And this probe has an autozero function built into the firmware.
The system worked pretty well, actually.
The first thing to notice is that airdata derived yaw was well correlated with the inclinometer. Yay! Obviously we need more data but this is really good news. I am ready to say that our yaw errors were basically zero offset problems that are solved by a simple startup autozero.
Secondly, airdata derived yaw was more sensitive than the inclinometer. We expected that, hoping that Airball would act as a "digital yaw string". It appears to do so.
Here is a bouncy phone video of Airball in some bumpy air:
I believe there is a "phase lag" caused by a delay which is in turn caused by our inadequate baud rate from probe to display -- I didn't have time to fix that yet.
Here is a nice shot of Airball showing the magenta TAS ring, and some yaw:
I tried calibrating VFE and VNO and found that the indication on my "installed" IAS is quite different from that measured by Airball. It was possible, however, to just set the bars to match what the installed IAS was saying, and from that point on things were very consistent. It was quite useful to be able to see VFE directly on the Airball.
Here are the next steps:
1. Increase baud rate. This is a no-brainer.
2. Increase digital filter time constant. The ball needs to be more "stable" so we can read it better.
3. Add a "shadow" ball with less filtering. To show the effects of turbulence consistent with the "digital yaw string" application, we can have a "shadow" ball that bounces around showing the instantaneous position. This allows the pilot to judge turbulence.
4. The ball should always be on-screen. In a full rudder deflection slip, the ball would often be off the screen. We need some visual that keeps it on the screen. For example, if the ball is past the right edge of the screen, the screen could look like this:
If we do that, we will have something that's close enough to be demo'able to third-party flight instructors. Stay tuned.
As you can see, the location of the display allowed me to compare the inclinometer and the Airball airdata-derived yaw quite easily.
The probe was mounted as usual, using our 3D printed mounts on the strut, extending near the leading edge. And this probe has an autozero function built into the firmware.
The system worked pretty well, actually.
The first thing to notice is that airdata derived yaw was well correlated with the inclinometer. Yay! Obviously we need more data but this is really good news. I am ready to say that our yaw errors were basically zero offset problems that are solved by a simple startup autozero.
Secondly, airdata derived yaw was more sensitive than the inclinometer. We expected that, hoping that Airball would act as a "digital yaw string". It appears to do so.
Here is a bouncy phone video of Airball in some bumpy air:
I believe there is a "phase lag" caused by a delay which is in turn caused by our inadequate baud rate from probe to display -- I didn't have time to fix that yet.
Here is a nice shot of Airball showing the magenta TAS ring, and some yaw:
I tried calibrating VFE and VNO and found that the indication on my "installed" IAS is quite different from that measured by Airball. It was possible, however, to just set the bars to match what the installed IAS was saying, and from that point on things were very consistent. It was quite useful to be able to see VFE directly on the Airball.
Here are the next steps:
1. Increase baud rate. This is a no-brainer.
2. Increase digital filter time constant. The ball needs to be more "stable" so we can read it better.
3. Add a "shadow" ball with less filtering. To show the effects of turbulence consistent with the "digital yaw string" application, we can have a "shadow" ball that bounces around showing the instantaneous position. This allows the pilot to judge turbulence.
4. The ball should always be on-screen. In a full rudder deflection slip, the ball would often be off the screen. We need some visual that keeps it on the screen. For example, if the ball is past the right edge of the screen, the screen could look like this:
If we do that, we will have something that's close enough to be demo'able to third-party flight instructors. Stay tuned.
No comments :
Post a Comment