60s tech may not always have been as sophisticated as today’s gear, but it was generally reliable and easy to understand. Automation, if implemented at all, was generally mechanical or electro-mechanical. While this was understandable with digital technology having barely gotten started, it meant that modifying or upgrading these systems required specialist equipment, usually only available to the device manufacturers.
My mom’s old Sears sewing machine is a good example of this. Bought by her parents in 1967 as a (very practical and rather expensive) wedding gift, it still works well today and with occasional oiling will probably still work well in a hundred years’ time. It is a purely electromechanical device — and the “electro-” part is confined to a variable-speed electric motor and a light bulb on a switch. A competent appliance tech from the 1920s would have understood it.
A 1967 Sears Kenmore sewing machine, showing the pattern disc compartment on top.
Despite all that, it’s actually programmable. Sort of. Like many higher-end sewing machines of the era, it has a provision for incorporating different stitch patterns. This is accomplished (on this machine) by a plastic disc that sits in a compartment on top of the machine. As fabric is fed through the machine, the disc rotates and a follower arm tracks along the outside of the disc, which has thickness variations corresponding to the intended deviation of the stitch pattern. Higher areas on the disc move the needle to the right; lower ones allow a spring to move it back to the left.
The disc library for the Sears sewing machine. (Not sure what happened to Disc 1…)
Production of bespoke plastic parts, back then, would have generally been done by hand, unless many copies were needed. A skilled tech would mark a design on a piece of plastic, then cut it out with a jigsaw and file it smooth. For larger runs, such as for the discs that came with the machine, copies would be injection-molded — individual parts cost next to nothing, but the tooling/NRE costs are large.
These days, making singleton custom plastic parts is easy. With a few measurements (would you believe these things are actually Metric?!?), it’s easy to generate a .STL file to get a 3D printer to make custom discs.
The relevant measurements are:
Center hole diameter: 25mm
Outer diameter: 53-57mm (radius of outer path is 27.5mm +- 1mm
Sometimes, 64 bits of resolution just isn’t enough — especially when floating point arithmetic only uses 53 of those bits for the significand. There are arbitrary-precision libraries out there, but it would be nice to have larger floating-point formats supported by the compiler.
It turns out that the floating-point units on x86 processors (32- and 64-bit) support an 80-bit “extended precision” type — and GCC/mingw supports this as type “long double.”
It’s not quite the 128 bits of floating-point goodness you’d expect based on sizeof(long double) — each such variable takes 128 bits — sixteen bytes — of space! Along with this extended precision, printf() now (once you know how to ask nicely) also will print digits to 62 points past the decimal place before switching to zeros. (Exactly how many of these digits mean anything is debatable, but at least it won’t introduce an artificial precision limitation.)
Using printf() and friends on long doubles works well: the format string is %Lf. In order for mingw to understand this format string, though, you’ll need to include the following line:
#define __USE_MINGW_ANSI_STDIO 1
I decided to see how the extra precision worked by computing pi. The algorithm I chose is numeric integration by the trapezoid method of 1/4 of the unit circle (and then multiplying by 4.) If your sums are precise enough, you should get roughly as many digits of Pi as the log10 of the number of samples.
I wrote the following program to compare the precision performance of <float> vs. <double> vs. <long double>. 32-bit floats stopped getting more accurate at 2^18 slices, and froze altogether at 2^25 slices (I suspect dx became indistinguishable from zero.) 64-bit double precision did better, overshooting a little at 2^38 slices. Long double is still going strong at 2^42 and might get another two digits (90 –> 89) on the next iteration. Maybe.
Printing the calculated digits of Pi at each resolution shows the differences:
Calculating pi using 32-bit float. The lack of precision literally stops it after a few seconds’ runtime.Calculating Pi using 64-bit double precision floating point. Better than Float, but we can do better yet. (It overshot on 2^39, which should not happen, and may be stuck on 2^40…)Calculating Pi using long double.
Comparing the latest result from <double> and <long double> — 2^39 — we get:
Float: 3.1416 (best result at 2^17; it then overshot and eventually hung) 64-bit Double: 3.1415926540781… (8 digits past the point) Long Double: 3.14159265359706… (10.5 digits; even the 9 is correct with rounding.)
Another question (which I’m not tracking this time) is how long each of these take, on the desktop computer as well as on the Samsung A71. The desktop may well be a lot faster at floating point — as an informal comparison, both the desktop and A71 were running overnight; the PC got to ~2^42 and the A71 got to ~2^36, both having started roughly at the same time and run for roughly ten hours. Each level takes as long as all previous levels, so a gap of six levels completed is a 2^6, or 64x, gap in performance.
Maybe it’s not time to retire the desktops for big-data calculations, after all.
While grading final exams and term projects, I often set up a long-haul flight in X-Plane as something to check in on to take a break now and then. I thought about using my usual Zibo mod 737-800, but noticed an ex-NASA “747-100” in the fleet listing.
“Oh — that old thing?” The dispatcher pulled a clipboard from the wall. “Ex-NASA 747-100 Space Shuttle Carrier…” He looked at the plane for a moment, seemed about to say something, then thought better of it. “Not sure where we downloaded it from, honestly. I think it’s been — no, being — refurbished to go to a museum somewhere. It needs to go to Anchorage for testing, next. We think we can get the FAA guy to sign off on a ferry permit if you want…”
Sure — why not, I thought. They fly 747s from Dulles to Anchorage all the time. Or at least, it’s a plausible route. If it’s really a -100, it will probably be VOR navigation only unless it has an INS. In that case, we could cheat and route directly to an initial approach fix. (I’m not a stickler for realism in routing, since I fly offline.)
I loaded the plane and was greeted by the flight deck you see above. This, plus the lack of Flight Engineer’s station, told me this was probably a -400, or at least using -400 glass-cockpit controls, with the steam gauges only as backup.
No problem, I thought. I can fly either style, but my life just got easier. And it did — sort of. I turned on the battery and lit the APU. Once it was up and running, I set it up to run the electrics. I then turned on the APU bleed and went to turn on the packs — but the switches were disabled. Maybe they need the engines to be running…?
Starting the engines was fun — the secret combination seemed to be to turn the fuel on and then pull the starter switch until it lights up. Kind of backwards from the 737 (fuel is the last step there, after 25% N2), but whatever. Four good engine starts. I was worried we wouldn’t have an EPR gauge for #2 , since it was acting weird and reading full scale when off and at idle, but it seems to work when the engines are at power. Eh — we’ll write it up for the team at Anchorage.
Once all four engines were running, I went to switch the engine bleeds on and turn on the packs. No dice — the switches were off and probably not modeled. After trying everything I could think of, I had a chat with Maintenance about it, and asked them to fix it. I switched on the Inertial Navigation units, so they’d have a chance to align.
I looked at the overhead panel. None of the hydraulic systems were on, although I’d tried pressing the relevant buttons. #4 was showing System Fault. Also, the hydraulic brake pressure was at zero. Nice. That should make for an exciting landing.
Fuel? The center panel says we have 150 (metric) tons. It doesn’t say which tanks this is in, or how much is in each, or what the fuel valve configuration is. That’s all on the Fuel screen, and the button naturally doesn’t work. Eh — hopefully the fuel guys are more competent than they looked. We’ll hope it’s fueled and configured correctly, and send it.
The maintenance guy stuck his head in the cockpit. “We can’t get the bleeds to work, but we found a bunch of oxygen canisters and bomber jackets for you guys so you can run unpressurized. Just pretend you’re flying a B-17. And don’t tell the FAA guy, hey?”
Well, that will be a new experience. Hopefully they’ll disable the passenger oxygen mask drop mechanism, because we don’t have any controls for that, either. Next, I looked at the Flight Management Computer (FMC). It looked professional enough until I started trying to get it to do anything. Oh, well. Old-school VORs it is. We have GPS/INS navigation, but no way of entering waypoints — or any way to tell what the names of the ones on the screen are.
By now, the IMCs had aligned (suspiciously quickly). I decided not to complain — maybe they’re GPS-assisted or something — and tried to put together a semblance of a takeoff checklist:
Flaps: I dunno. Let’s try 10. That’s what the chart would say if we had one, right?
Autobrake: (We seem to have the world’s only 747 without autobrakes. Nice.)
Flight Directors: On. (Oh, hey — they work!)
Heading: Set to 011
Altitude: Set to 32,000
With the definite thought that there’s no way I’d be taking this disaster into the air if this weren’t a simulation, I shrugged, advanced the throttles, and released the brakes, and watched as the 747 performed a beautiful, graceful takeoff almost on its own. That’s a relief, I thought, since we didn’t have any trim setting guidance either, so that was also a guess.
I pulled up the gear and flaps, engaged the autopilot and got it pointed towards the first VOR, then looked for the OBS dial to set up a direct course. Weirdly, I couldn’t locate it by the time we had passed the VOR, so I tuned to the second one and continued steering it in Heading mode. After a very thorough fifteen-minute search, I realized that the OBS dial didn’t exist. So we can tune VORs, but we can’t tell the plane which radial to use. Sigh. Time to add in some keyboard commands to set it and hope that works. (How the hell are we gonna fly the ILS approach, otherwise?)
Hacking in OBS functionality with keyboard commands worked — but then the plane seemed to get confused. The HSI display on the 744 (and this Frankenplane’s nose was a 744, even if the back end was a 741 and who knew what the wing and engines were from) only showed a sliver of the entire circle, for visibility. What I couldn’t see was that the arrow I had aligned with the VOR was actually the backcourse arrow. The plane, thinking it was being asked to follow an easterly course, wavered and then began a turn back east before being put back on Heading mode. Bad plane. No cookie!
Maybe it’s reverse-sensing? Still in Heading mode, I turned the OBI 180 degrees. This side had a larger arrow — which would have been obvious on a full-scale display. Mystery solved. We may not have full automation, but we can track radials, now.
Well, sort of. The nav display doesn’t seem to make sense. Planes generally don’t quite point in the same direction they’re going, of course — they have to turn slightly (crab) to account for wind drift. This display had a heading bug and indicator, a track direction indicator, and a VOR radial indicator, no two of which generally agreed during the flight unless going directly upwind.
Even somewhat-accurate navigation will still get you from VOR to VOR, though, so I was able to get it to slowly make its way across the US and Canada, headed for Anchorage. It soon reached its cruise altitude of 32,000′, which was when I discovered that the autothrottle didn’t work well, either. The plane levelled off just fine, but kept increasing and decreasing the throttles every few seconds, chasing small variations in wind. I turned it off and set the throttles manually, and almost didn’t have to touch them for the rest of the cruise.
It was while setting the throttles for cruise speed that I noticed the single most iconic thing about this plane. Ships have their bell as the “soul” of the ship. This mess of a 747-whatever had its very own factory-seconds indicated airspeed (IAS) gauge, centrally placed to inform its hapless crew that while they may be flying the Queen of the Skies, this particular Queen was built on a Friday afternoon and modified on a Monday morning, so keep your eyes open.
That “350” should be “320.” At least, if we can trust the main IAS tape. 250-300-350-400 would make more sense, but that’s not how it works, unfortunately.
It’s glorious, and explains everything about this poor plane.
I managed to get it the rest of the way to Anchorage and get lined up for the 07R ILS, and it made a beautiful landing — as with the takeoff, almost completely by itself. The 747 — even a broken, confused one — is an amazing machine. The brakes even somehow worked, which was surprising given the lack of hydraulic pressure.
But yeah. Don’t buy jumbo jets from shady NASA guys in trench coats, kids. I’m flying the Zibo back East and sending this bird to Maintenance before something else breaks.
Don’t look now, but that smartphone you’re carrying might be faster than your desktop. Even if not, modern smartphones are certainly capable enough to be used for many computing tasks traditionally left to desktops and laptops.
Smartphones typically have a single USB port — either MicroUSB or USB-C. For something like ten years now, these have generally all been capable of “USB On-The-Go” (USB-OTG) operations, where the smartphone switches functionality from USB device to USB controller. Plug in an inexpensive USB On-The-Go adapter, and your smartphone can access most of the same USB devices your desktop and laptop can. They can read and write flash drives, use USB keyboards and mice — and even program Arduino-compatible boards.
A Samsung A71 5G programming a TTGO T-Display via ArduinoDroid. This is the whole setup — no PC is needed (for simple sketches, anyway.) Even the Bluetooth keyboard is technically a luxury — if a very useful one!
I recently used a similar setup for troubleshooting a faulty speed sensor on a friend’s boat. A smartphone and Bluetooth keyboard are portable enough to use on board, where a laptop would be awkward and a desktop almost impossible to use.
I’ve started carrying a USB On-The-Go adapter with me. I figure if I’m already carrying the supercomputer, I might as well bring a USB port for it along.
