EE Times EDN DataSheets.com Design News EBN Test & Measurement World Embedded.com TechOnline Planet Analog
Events ▼
UBM Electronics

Contact Us • Subscribe to Newsletters

JackCrens

's profile
image
Research & Development Engineering Management
Jack Crenshaw is a systems engineer and the author of Math Toolkit for Real-Time Programming. He holds a PhD in physics from Auburn University. E-mail him at jcrens@earthlink.net.

JackCrens

's contributions
Articles
Comments
Discussions

    • Understanding the intimate relationship between vectors and reality means means understanding vectors, their properties, and how to manipulate them.

    • In the February, 1992 issue of Embedded Systems Programming, a new column, Programmer's Toolbox, was introduced. The name was not chosen at random: The intent of the column is to provide useful tools and techniques that readers can apply to their own problems in embedded systems development. The idea is to have a library of reusable modules. written in several languages, that others can use to avoid re-invention of the wheel and improve their productivity and software quality. In this paper, I'll describe the thoughts behind the column. the software tools that have already been presented, the ones yet to come, and the ultimate goal of the effort. A successful effort will require support from the user community. Part of the message of this paper is a plea for help and feedback.

    • If you've studied calculus at all, you learned early on a sad but true fact of life: There are many more calculus problems that can't be solved than there are problems that can be. Getting a neat, closed-form solution to a tough problem is always satisfying, and makes a mathematician or physicist feel like a real hero. But in that real world, no closed-form solution ever seems to exist for the problem that's facing us at the moment. So when an integral or derivative can't be found ... when that elusive closed-form solution doesn't exist ... what do we do?

    • Take a trip through the life's work of one engineer who was involved in embedded systems from Day 1 (courtesy of Rambling Jack).

    • Understand how to cut down on the noise in your system, using the math behind the Kalman filter.

    • You need math to estimate a curve. Here's part two in Jack's series on state estimation.

    • Was someone at PTC listening to Jack when they created Mathcad Prime 1.0?

    • On the road to the Kalman filter: The job of the least squares fit is to give an estimate of the unknown coefficients of the mental model.

    • Jack Crenshaw tells you how to calculate trajectories to get your space craft to the Moon and back.

    • Test your software over and over during its development stage, even if your manager doesn't like it. You answer to a higher customer.

    • I'm very sorry to keep all my readers waiting. It's not my usual way of doing business. I'm well aware that, because I tend to write multiple related columns, I owe it to you guys to keep 'em coming. In my defense, I can only say: Two really vicious computer malware attacks, one heart surgery, seven weeks of in-home therapy, and two sessions in civil court. Please be patient, folks. I'm pedaling as fast as I can.

    • Ridgerat, your last sentence says it all: We are still only at the beginning of the story. Two points: First, it's true that the KF needs a model. I've tried to emphasize that point. In most uses of the KF for guidance & control, etc., the model is based on the laws of physics. But it needn't be that way -- a purely math-based model, like a polynomial or Fourier series, is a perfectly valid model. And yes, the recursive least squares in my examples fits your one-step predictive requirement. Look at the graphs again. At any given step, you have your best estimate of the state, which in the examples are the coefficients of a polynomial. Using those coefficients, you predict the value of f(x) you expect to get at the next measurement time. Then you compare it to the actual measurement, and update the estimate of state. See my Equation 3: e = y - y_bar. The y_bar is the prediction, y the measurement. Second, please don't be misled by the notation. I've been using x as the independent variable, and y as the dependent variable, because that's the traditional form for both the function y = f(x), and the graphical notion of the x-y graph. In the KF, the independent variable is something else; usually time, or the discrete equivalent of it. The state variables are x, and the measurables are y. I was going to get around to that, but I didn't want to throw a change of notation into the mix yet. You jumped ahead of me. In the end, the difference between a least-square solution and the KF is almost exclusively the optimal use of the covariance matrix. We'll get around to that.

    • You are so right!!! Sorry.

    • Don't worry, we'll be covering probabilities and distribution functions in quite some depth. I just think it's pretty interesting how much good stuff you can get done without them.

    • "By this definition, yes, Gauss' calculations were "real time" " Grin! I knew I was going to get into trouble with this one. You're absolutely right, of course. The time when the data is needed matters, and Gauss didn't need the results for a year or so. On the other hand, the measurements were taken only days or weeks apart, so Gauss had all his measurements before he started. The method he used was indeed batch.

    • Lots of folks commented on my lack of concern for overflow,and I guess that theoretically you're all right. But c'mon, guys: Get real. The issue is not the best possible way to sum billions of numbers. The whole point of the exercise was to show how an inherently batch process can be warped into a sequential one. If, in the real world, you're writing software that finds the average of a billion numbers, I have to gently suggest that you're using the wrong algorithm. Even when you think you know that the thing you're measuring is very nearly constant, are you quite sure that it's NEVER going to change? What about sensor variations with anbient temperature? What about drift in the reference voltage? Please concentrate on the general ideas. Don't get lost in the forest of trivia. in the case of something as "constant" as the speed of light, we can't be 100% certain that it is

    • About reliability: Around 1999-2000 I went through an orgy of buying old Heathkits on eBay. The thing that amazed me was how many of these 40-year-old kits still worked, and worked nicely. My pals all told me that I'd have to replace all the electrolytic caps, that I'd have to replace the tubes, and that I'd better bring the units up on a Variac to make sure I didn't smoke'em. I did none of that. Oh, sure, some of the units were non-functional or way out of spec. But the majority of them simply came up, and worked as well as when they were new. For a time, I used to check all the electrolytics, as my pals suggested. But every time I tested one, I found it not only good, but with the correct capacitance. After awhile, it just got too boring. I went through the test equipment first. In fact, one of the earliest purchases was a tube tester. Then I tried a few to see which units were still working at shop quality. After that, I used my best units like the VTVM to test everything else.

    • Mike: Good point re vacuum tube audio. Most of Heathkit's solid state amps,etc., near the end of their reign had a lot of bells and whistles. I used to call it "trying to out-knob the Japanese." Not a good plan, that. But today, there's a definite market for a simple kit, without all the frills. What red-blooded American audio enthusiast wouldn't love th build an updated version of the Dynakit or W-7M?

    • More on kits, modularity, learning, etc.: When I was 12, someone came out with a single-tube radio receiver kit. using all that cheap surplus electronics. It was your prototypical breadboard kit: the 1/4" plywood board and a layout pictorial came with the kit. You just glued the pic to the board, then started mounting parts. No soldering necessary. You screwed a bunch of Fahnstock clips into the board. Also the prewired tube socket, variable condenser, and coil. A cheap headphone and a 45-volt battery was also included. I was told years later that the tube was one of a line of military low-voltage tubes. The circuit was a regen. You adjusted a feedback coil until the circuit was right on the verge of squealing. A really simple circuit, but with a long outside antenna, I got great reception, esp. at night. Later, the same guys brought out an audio amp for it. Another 1-tube, battery-powered kit, but it drove a cheap 5 x 7 speaker, complete with mounting board and grille. The combo gave me many hours of pleasant listening. Now here's the point: If those same guys had offered an FM receiver kit, a multiband option, a superhet upgrade, perhaps a battery eliminator, etc., I would have bought each one. Up to and including a push-pull audio amp, a preamp with tone controls, etc., etc. All on plywood boards with Fahnstock clips. I would have been deliriously happy to have my whole bedroom full of that stuff. I've always wished Heath had come out with Microprocessor kits that worked the same way. Get some little something, like perhaps the 6800 educational kit. Something real simple and easy. Forget high clock speed; 100 KHz would be just fine. Heck, 1 KHz would be fine for learning. But also add a bunch of upgrade kits, including a floppy drive (I guess nowadays we'd use flash cards), a simple OS and assembler, etc., etc. Just keep those upgrades coming.

    • Jack, are you sure about that light bulb in the audio oscillator? In the Wien Bridge circuit of the AG-9a, the bulb was in one leg of an impedance bridge. Its temperature-sensitive resistance kept the positive feedback gain just enough to give a stable output amplitude. The AG-9a had a distortion level to die for. I bought one during my eBay orgy. When I tested it for harmonic distortion (40+ years after it was new) and nulled out the fundamental, the only thing I could see on a scope was a little hum and some white noise. Awesome.