Converting a WW2-Era Engine Cowl Flaps Indicator into a USB Peripheral
bikerglen.com
bikerglen.com
The current in all three potentiometer terminals is limited to 25 mA. The terminal with the maximum current is not the wiper, but the end terminal which carries both the wiper current and the end-to-end current. So the part needs to handle 15 mA, not 10 mA.
It is also good to calculate the power dissipated by the potentiometer. By inspection, the Thévenin equivalent circuit of the indicator is a 12 v supply in series with (1800/2+300) = 1200 ohms. The maximum power transfer with occur when the potentiometer is also presenting 1200 ohms. This is not at either end of travel!
Going through the algebra it looks like 1200 ohms (greatest dissipation) happens at 40% of the potentiometer's travel. It's still only 124 mW, so this part is well within its 1 W absmax.
- The indicator is ratiometric and the exact supply voltage doesn't matter. If it works acceptably well down at the +5 V USB bus voltage, the circuit would get a lot simpler.
- I suspect that driving the circuit with a variable voltage is sufficient, and the potentiometer is unnecessarily. Then a DAC or PWM with a plain old opamp would do the job.
On the power, I get a maximum power dissipation through R(AW) and R(WB) of 130 mW at R(AW) = 432 Ohms and R(WB) = 5000 - R(AB) = 4586 Ohms. Work is on my post.
The meters don't work well below about 18 Volts. The needle just doesn't quite make it all the way to open. My theory is the current is too small at lower voltages to completely overcome the force of the spring that pulls the needle to the out-of-range position when powered off. If the internal 300 Ohm resistance of the meter could be changed easily, then a lower voltage could work.
And yep, a DAC or PWM with an op amp with some gain would certainly work. For a lot of my past meter projects where the voltages required were 5 Volts or less, I've gone the PWM route with great success.
One question: is there any way to match such a device to an UI element in Windows, so that a physical knob can change the value of a slider element or a physical gauge showing a value for a software gauge/progress bar?
There used to be tools that allowed to click UI elements in a different program and change properties of these, e.g. setting a disabled UI element to enabled or reading out a value from a password field. That was 20 years ago though, so it might be possible that Windows is separating different programs more strictly these days.
I need to work on a C# app to demonstrate the landing gear and flaps indicator next though. It's working in Linux using a CLI but the Windows GUI makes the demo videos easier.
I'm not aware of any way to access dialog box elements using an API but I'm also not really a Windows developer either. I thought back in the day COM was supposed to enable sharing app elements and data using OLE and ActiveX. But all that Windows tech is beyond me.
Closest thing I can think of would be a bar code reader always having focus of one particular box on a form but I don't know how that works.
From the article: "In this meter, there’s also a small spring on each rotor that pulls the needles out of the minimum and maximum scale region when the meter has no DC power." Which makes sense in an application where "retain the last value" is a bad idea.
The question is, I think, "what setting would be least likely to cause a dangerous situation, if the indicator failed and the crew did not realize it had?" My guess is that the least desirable "home" position is fully-open, if it would usually be important to have the cowl flaps fully open during takeoff and initial climb-out to avoid engine overheating. Fully-closed may also be undesirable, if there are cases when having them closed is important (maybe with an engine fire, to minimize airflow and keep the fire-extinguishing agents in place, or after an engine failure, to reduce drag?) Intermediate positions would be chosen with reference to the cylinder head temperature, so the specific reading of the cowl-flap indicator might be less important.
Or maybe its just that, for a differential instrument, the middle is an unbiased home?
There are of course other instruments that do different things to indicate failure of gauge, failure of sensor, failure of connection, and so forth.
I have several of these older aircraft gauges, and other mechanical and analogue gauges from various devices in my workshop in a drawer, and taking them apart over the years, I can honestly say I have not found one from a particular manufacturer that is quite the same as another in mechanical operation from another manufacturer, and also mechanical differences between different instruments for different functionality. I've also found that when used in regular operation, i.e. wired up precisely how they are supposed to work, some instrument gauges would make a sort of wobble motion until they settled, like the amperage when applied would drop, come back up, go over, and then return to nominal. Old analogue circuits and capacitors hold charge, and take a while to settle, so it is always fascinating to watch these devices "do their thing" in their natural habitat.
My knowledge of aircraft systems, beyond tinkering with old gauges, is limited and I readily admit ignorance in most of this stuff.
IANAL but if it's a publication of the US government, I believe it should be in the public domain.
Plus, many documents won’t actually exist until someone asks (FOIA, things like that).
That is, the cost comes from somebody having to dig up the original document in paper or microfilm, scan it, and then put it up on the document site. And then all the kinds of overhead costs associated with having an physical and electronic archive like that (facilities, salaries etc.).
If everybody on the planet suddenly develops an acute interest in WWII era cowl flap indicators, sure, the above costs amortized over billions of downloads would be very close to zero. But presumably the government guesses that this document might be downloaded maybe a hundred times over the following decades and prices accordingly.
My preferred method is picking a project and starting to acquire knowledge to realize it. There is plenty of stuff on YT to learn from.
"The Art of Electronics" is brilliantly written bible on everything analog and some things digital, and it starts from pretty basic stuff. It is a bit pricy tho.
It follows a format on starting with something basic like "how amplifier" works, then going into details, all of them with real, useful examples and the whole road to figure out how to make those example from scratch.
It's not "guide to electronics" per se (although it does teach stuff well), as much as reference guide on "how to do X", except that the whole way to get X is explained so on top of recipe you're getting all the reasoning behind it.
EEVBlog forums are also nice place to ask: https://www.eevblog.com/forum/beginners/
You will not get to this level of understanding with your first project, but you also do not build a high performance distributed system as your Hello World! project in a new framework/language. Start with simple things like the usual blinky. Then start blinking two LEDs. Then you can figure out how to blink 4 LEDs independently with only three pins. Use a button to toggle LEDs, use transistors to switch LEDs, use optocoupler to switch LEDs, read the position of a potentiometer via an ADC, shift the ADC value with a resistor in series/parallel, read multiple buttons via a single pin/ADC, control the brightness of an LED via PWM, control a servo via PWM, read the position of a feedback servo via ADC, return a feedback servo to a recorded position on button press. Essentially every little project adds another thing to your toolbox. The fun is both in learning these things and combining them to achieve something else, like that returning servo.
Another aspect is, if you are doing this for fun, just follow the rabbit holes as you come across them. So you start wondering how that feedback servo works? Then you find there is a potentiometer in there, so you learn how that works. That will teach you about the relation between resistance and voltage drop. Or you treat it as a black box, because you just want to 3D print a robot arm, that is also fine. You will also start understanding simple circuit diagrams and try to draw your own. This helps later, because you can look at other people's projects and learn from them easier. Every time you get stuck or are wondering about something, you can just throw it into your favorite search engine and get blogs, questions, videos or anything else about it.
I want to throw in a recommendation for BigClive [1], because he does circuit reverse engineering, explanations, tips for modifying existing products and overall is just entertaining to watch if nothing else. If you want a video to start with, I can absolutely recommend [2], he goes over common components (resistors, transistors etc.) and explains how they work and what you do with them.
As a last point, I can recommend learning to solder, but it is not required at all to get started. A breadboard will serve you a long time, but once you want to make some more permanent circuits or want to modify existing things, it is a very handy and simple skill. On the other hand, my most permanent circuit is still on its original breadboard...
[1] https://www.youtube.com/@bigclivedotcom [2] https://www.youtube.com/watch?v=6Maq5IyHSuc
For surface mount soldering, you need good tweezers, a good soldering station, and magnification. Cheap USB microscopes are helpful.
DCS-BIOS[3] is a similar project for interacting with DCS.
There's something really, really neat about seeing real physical instruments spinning around in response to a computer game. And they're actually often a lot easier to use than the instruments in-game, too.
* Frantic Googling *
Oohhhh! So that's what it is! How useful!